অ্যাক্টিভেকর্ড প্যাটার্নের ত্রুটিগুলি কী কী?

Question

ডেটা অ্যাক্সেস / ব্যবসায়িক অবজেক্টের জন্য অ্যাক্টিভেকর্ড প্যাটার্নটি ব্যবহার করার ক্ষেত্রে কী কী ত্রুটি রয়েছে তা আমি আগ্রহী। আমার মাথার উপরের অংশটি কেবলমাত্র আমিই ভাবতে পারি যে এটি একক দায়িত্বের নীতি লঙ্ঘন করে, তবে এআর প্যাটার্নটি যথেষ্ট সাধারণ যে এই কারণটি ব্যবহার না করে ন্যায়সঙ্গত করার জন্য এই কারণটি একা "যথেষ্ট যথেষ্ট" বলে মনে হয় না (অবশ্যই আমার দৃশ্য প্রায়ই কোড আমি কাজ অনুসরণ সঙ্গে কেউ যেহেতু স্কিউ হতে পারে কোনো কঠিন নীতির)।

ব্যক্তিগতভাবে আমি না কারণ এটি বর্গ মত আর খুব বেশী করছে (ক উপর রুবি পাগল আবেদন, যেখানে শিরোণামে মতানুযায়ী "স্বাভাবিক" লেখা বাদে) ActiveRecord একটি পাখা, এবং তথ্য অ্যাক্সেস বর্গ নিজেই পর্যন্ত করা উচিত হবে না পরিচালনা করতে. আমি ব্যবসায়িক বিষয়গুলি ফেরত দেওয়ার জন্য সংগ্রহস্থলগুলি ব্যবহার করতে পছন্দ করি। আমি যে কোডটি নিয়ে কাজ করি সেগুলির বেশিরভাগটিতে অ্যাক্টিভেকর্ডের একটি প্রকরণটি ব্যবহার করা হয়, (এই পদ্ধতিটি কেন বুলিয়ান তা আমি জানি না):

public class Foo
{
    // properties...

    public Foo(int fooID)
    {
        this.fooID = fooID;
    }

    public bool Load()
    {
        // DB stuff here...
        // map DataReader to properties...

        bool returnCode = false;
        if (dr.HasRows)
            returnCode = true;

        return returnCode;
    }
}

বা কখনও কখনও public static Foo FindFooByID(int fooID)সন্ধানকারীদের জন্য পদ্ধতি এবং public void Save()সংরক্ষণ / আপডেটের রেখার পাশাপাশি কিছু "প্রথাগত" হওয়ার উপায় ।

আমি পেয়েছি যে অ্যাক্টিভেকর্ডটি সাধারণত প্রয়োগ এবং ব্যবহারের জন্য খুব সহজ , তবে জটিল অ্যাপ্লিকেশনগুলির জন্য এটি কিছুটা সহজ বলে মনে হয় এবং কোনও রেপোসটরিতে আপনার ডেটা অ্যাক্সেস লজিককে আবদ্ধ করে আপনি আরও শক্তিশালী আর্কিটেকচারটি পেতে পারেন (এটিকে সোজা আউট করার পক্ষে সহজ কথা বলার অপেক্ষা রাখে না) ডেটা অ্যাক্সেস কৌশলগুলি উদাহরণস্বরূপ আপনি স্টোরড প্রোকস + ডেটাসেটগুলি ব্যবহার করতে পারেন এবং লিনকিউ বা কিছুতে স্যুইচ করতে চান)

তাহলে এই প্যাটার্নের অন্যান্য কী কী ত্রুটি রয়েছে যেগুলি যদি সিদ্ধান্ত নেওয়ার সময় অ্যাক্টিভেকর্ডটি সেরা প্রার্থী হয় তবে তা বিবেচনা করা উচিত?

Answer 1

প্রধান অসুবিধা হ'ল আপনার "সত্তা" তাদের নিজের অধ্যবসায়ের বিষয়ে সচেতন যা অনেকগুলি খারাপ নকশার সিদ্ধান্ত নিয়ে যায়।

অন্যান্য সমস্যাগুলি হ'ল সর্বাধিক সক্রিয় রেকর্ড টুলকিটগুলি মূলত 1 থেকে 1 টেবিল ক্ষেত্রগুলিকে ইন্ডিয়ারেশনের শূন্য স্তর সহ ম্যাপ করে। এটি ছোট আকারের স্কেলগুলিতে কাজ করে তবে যখন সমস্যা সমাধানের জন্য আপনার আরও জটিল সমস্যা হয় তখন তা পৃথক হয়ে যায়।

---

ঠিক আছে, আপনার বস্তুগুলি তাদের অধ্যবসায়ের বিষয়ে জেনে রাখার অর্থ আপনার মতো কাজগুলি করা দরকার:

• সহজেই যেকোন জায়গায় ডাটাবেস সংযোগ উপলব্ধ রয়েছে। এটি সাধারণত দুষ্টু হার্ডকোডিং বা কোনও ধরণের স্থির সংযোগের দিকে নিয়ে যায় যা সর্বত্র থেকে আঘাত হানে।
• আপনার বস্তুগুলি বস্তুর চেয়ে এসকিউএল এর মতো দেখতে আরও ঝোঁক।
• অ্যাপ্লিকেশনটিতে সংযোগ বিচ্ছিন্নভাবে কিছু করা কঠিন কারণ ডেটাবেস এতটাই সংযুক্ত।

এর শীর্ষে অন্যান্য খারাপ সিদ্ধান্তের পুরোপুরি হ'ল শেষ।

Comments

আপনি কি "অন্যান্য খারাপ নকশার সিদ্ধান্তগুলি" সম্পর্কে বিস্তারিত বলতে পারেন?

— কেভিন

ধন্যবাদ। এই বিষয়গুলিকে আমি রুবে অন রেলস বিকাশের জন্য সমস্যা হিসাবে পাইনি। আচরণ এবং অধ্যবসাকে আলাদাভাবে পরীক্ষা করা এখনও সম্ভব। আচরণ থেকে অধ্যবসায়কে আলাদা করা আইএমওর ব্যবহারিক মূল্য খুব কম।

— কেভিন 13-18

@ কেভিন: এই জিনিসগুলি রুবি বৈশিষ্ট্যগুলির সাথে মিক্সিন এবং হাঁসের টাইপিংয়ের মতো কমতি রয়েছে। অবিচলিত ভাষাগুলির সাথে - সি # এর মতো যা ওপি তার প্রশ্নের মধ্যে কী ব্যবহার করেছিল - দুটি আলাদা করা আরও কিছুটা কঠিন।

— ওয়াইয়াট বার্নেট

@ ওয়াইন: আমার কাছে, ক্লাসগুলি পদ্ধতি স্থাপনের জন্য কেবল বাক্স - আমি ব্যবসায়ের যুক্তিগুলিকে পৃথক ক্লাসে স্থাপন করে অধ্যবসায় থেকে পৃথক করতে পারি, বা ব্যবসায়ের পদ্ধতিগুলি আমি / না করে তা নিশ্চিত করে আমি কেবল তাদের ধারণামূলকভাবে পৃথক করতে পারি / মন্ত্রণালয় দুর্বল প্রতিনিধি সমর্থন সহ ভাষাগুলিতে (যেমন জাভা), এটি বিপুল পরিমাণ কোড সাশ্রয় করে। ওও, আমি ঠিক হাইবারনেটে gettingুকছি যাতে আমি সম্পূর্ণ ভুল হতে পারি।

— কেভিন cline

আমি দুটি জিনিস যোগ করা হবে; ১. অধ্যবসায় ব্যবস্থার সাথে মিলনের ফলে কোডটি যথাযথভাবে ইউনিট পরীক্ষা করা কঠিন, যদি অসম্ভব না ঘটে makes ২. অ্যাক্টিভ রেকর্ড আপনার কোডটিকে কেন্দ্রীয়ীকরণের দৃ pers়তা ব্যবস্থার সাথে সম্পর্কের দিকে আটকায়, যদি আপনি কখনও সিদ্ধান্ত নেন তবে আপনার একরঙাটিকে বিভক্ত করা সত্যিই কঠিন হয়ে পড়ে।

— istepaniuk

Answer 2

সক্রিয় রেকর্ডের সবচেয়ে বড় অসুবিধা হ'ল আপনার ডোমেনটি সাধারণত একটি নির্দিষ্ট দৃ a়তা ব্যবস্থার সাথে দৃ tight়ভাবে মিলিত হয়। সেই প্রক্রিয়াটির জন্য কি কোনও বিশ্বব্যাপী পরিবর্তন প্রয়োজন, সম্ভবত ফাইল-ভিত্তিক থেকে ডিবি-ভিত্তিক অধ্যবসায় বা ডেটা অ্যাক্সেস ফ্রেমওয়ার্কের মধ্যে, এই প্যাটার্নটি প্রয়োগ করে এমন প্রতিটি শ্রেণি পরিবর্তিত হতে পারে। ভাষা, কাঠামো এবং নকশার উপর নির্ভর করে এমনকি ডিবি যেখানে রয়েছে তার পরিবর্তনের মতো এত সাধারণ কিছু বা যিনি "মালিকানাধীন" এটি ডেটা অ্যাক্সেসের পদ্ধতিগুলি আপডেট করার জন্য প্রতিটি বস্তুর মধ্য দিয়ে যেতে পারে (এটি বেশিরভাগ ভাষায় অস্বাভাবিক যা সহজ অ্যাক্সেস সরবরাহ করে সংযোগ স্ট্রিং সহ ফাইলগুলি কনফিগার করতে)।

এটি সাধারণত আপনার নিজের পুনরাবৃত্তি করা প্রয়োজন। কোনও ডিবিতে সংযোগ স্থাপন এবং লেনদেন শুরু করতে বেশিরভাগ অধ্যবসায় ব্যবস্থার প্রচুর প্রচলিত কোড থাকে। DRY (নিজেকে পুনরাবৃত্তি করবেন না) আপনাকে এই জাতীয় যুক্তিটিকে কেন্দ্রিক করার কোডার হিসাবে বলবে।

এটি পারমাণবিক অপারেশনকেও জটিল করে তোলে। যদি কোনও গ্রুপের অবজেক্টগুলি অবশ্যই সমস্ত-বা-কিছুই ফ্যাশনে সংরক্ষণ করা উচিত (যেমন একটি চালান এবং তার চালানলাইন এবং / অথবা গ্রাহক এবং / অথবা জিএল এন্ট্রি), কোনও একটি বস্তুকে অবশ্যই এই সমস্ত বস্তুর সম্পর্কে জানতে হবে এবং তাদের দৃistence়তা নিয়ন্ত্রণ করতে হবে ( যা নিয়ন্ত্রণকারী অবজেক্টের ক্ষেত্রকে প্রসারিত করে; বড় আন্তঃসংযুক্ত রেকর্ডগুলি সহজেই "godশ্বর বস্তু" হয়ে উঠতে পারে যা তাদের নির্ভরতা সম্পর্কে সমস্ত কিছু জানে) বা পুরো লেনদেনের নিয়ন্ত্রণ অবশ্যই ডোমেনের বাইরে থেকে পরিচালনা করা উচিত (এবং সেই ক্ষেত্রে আপনি কেন ব্যবহার করছেন? শিরোণামে?)

এটি কোনও অবজেক্ট-ওরিয়েন্টেড দৃষ্টিকোণ থেকে "ভুল"। বাস্তব বিশ্বে, একটি চালান কীভাবে নিজেকে ফাইল করতে হয় তা জানে না, তবে কোনও চালান কোড অবজেক্ট নিজেকে ডিবিতে কীভাবে সংরক্ষণ করবেন তা কেন জানবে? অবশ্যই, "বস্তুগুলির অত্যধিক ধর্মীয় অনুষঙ্গগুলি কেবলমাত্র তাদের বাস্তব-বিশ্বের অংশীদাররা কি করতে পারে তা মডেল করা উচিত" রক্তস্বল্প ডোমেন মডেলগুলির দিকে পরিচালিত করে (একটি চালানও তার নিজস্ব মোটের গণনা কীভাবে করতে পারে তা জানে না, তবে সেই মোটের গণনা বিভক্ত করে অন্য একটি বস্তুকে সাধারণত একটি খারাপ ধারণা হিসাবে বিবেচনা করা হয়)।

Comments

রুবিতে, যেখানে অধ্যবসায়ের সংজ্ঞা দেওয়া যেতে পারে বা খুব সাধারণ কীওয়ার্ড বা কমান্ডের পিছনে বিমূর্ত করা যায়, সম্ভবত এটি কোনও সমস্যা কম। .NET- এ, যার জন্য বিভিন্ন অধ্যবসায় ব্যবস্থা গ্রহণের জন্য আরও এলওসি প্রয়োজন, প্রতিটি বস্তুর জন্য একটি এসকিউএল সংযোগ থাকা সাধারণত অযৌক্তিক হয়, বিশেষত যদি একাধিক বস্তু একটি পরমাণু লেনদেনে সংরক্ষণ করতে হয়। আপনি কোনও চালান বা গ্রাহককে সংরক্ষণ করছেন কিনা তা ডিবিতে সংযুক্ত হওয়া একই দেখায়। আপনি হয় আপনার কোডবেজে সমস্ত অ্যাক্টিভেকর্ড অবজেক্টের জন্য সাধারণ স্টাফটিকে বেস ক্লাসে বিমূর্ত করতে বা এটি নিজস্ব শ্রেণিতে (একটি

— সংগ্রহশালা

আপনি কি রুবি অ্যাক্টিভেকর্ড ব্যবহারের উদাহরণ প্রদান করতে পারেন যা আপনার পয়েন্টগুলি চিত্রিত করে? আমি এই সমস্যাগুলি অনুভব করিনি, তবে আমার অ্যাপ্লিকেশনটি মোটামুটি ছোট ছিল। আমি রুবিতে মাইগ্রেশন লিখতে এবং সেগুলি ডিবি বাস্তবায়নের ক্ষেত্রে পৃথক করতে পারি। আমি দেখতে পেলাম যে রুবির অ্যাক্টিভেকর্ড পুনরাবৃত্তি দূর করতে খুব দরকারী, তাই আপনি দেখতে পাচ্ছেন না যে আপনি কেন অ্যাক্টিভেকর্ড ব্যবহার করে তার বিপরীত প্রভাব ফেলবেন। সংরক্ষণে আমার কোনও সমস্যা হয়নি: আমি কেবলমাত্র অবজেক্টের মডেলটি সংশোধন করেছি, এবং এআরকে অবজেক্টের মডেলটি প্রতিবিম্বিত করতে ডিবি আপডেট করতে দিন।

— কেভিন ক্লিন

Answer 3

মূল অসুবিধাটি হ'ল এটি আপনার ডোমেন মডেলটিকে জটিল করে তোলে কারণ এটি কেবল ব্যবসায়িক যুক্তিই রাখে না তবে দৃistence়তার তথ্যও রাখে।

সুতরাং সমাধানটি হল ওআরএমের ডেটা ম্যাপার প্রয়োগকরণকে ব্যবহার করা । এটি অধ্যবসায় স্তরটিকে পৃথক করে এবং সত্তা ব্যবসায়িক যুক্তিতে আমরা এখন আরও কেন্দ্রিক। মতবাদ হ'ল ডেটা ম্যাপার ওআরএম।

তবে এই পদ্ধতিরও কিছু জটিলতা রয়েছে, ক্যোয়ারির জন্য এখন আপনি ডেটা ম্যাপারের উপর নির্ভরশীল, ক্যোয়ারী ওরিয়েন্টেড পরিবেশ তৈরি করেছেন। এটি সরলকরণের জন্য ডোমেন মডেল এবং ডেটা ম্যাপারের মধ্যে আরেকটি স্তর চালু করা হয় তাকে রিপোজিটরি বলে ।

সংগ্রহস্থল অধ্যবসায় স্তর স্তর বিমূর্ত। এটি অর্থে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের অনুভূতি বোধ করে, এটি হ'ল সমস্ত ধরণের অবজেক্টের সংগ্রহ (যেমন ডাটাবেস সারণিতে সঞ্চিত সমস্ত সত্তা) এবং আপনি সংগ্রহ অপারেশন হিসাবে তাদের উপর ক্রিয়াকলাপ পরিচালনা করতে পারেন, যোগ করতে পারেন , সরিয়ে ফেলতে পারেন । ইত্যাদি রয়েছে

ব্যবহারকারীর সত্তার উদাহরণস্বরূপ , সেখানে ব্যবহারকারীর রিপোজিটরি থাকবে যা একই ধরণের ব্যবহারকারীর অবজেক্টগুলির (যা ব্যবহারকারীদের সারণীতে সঞ্চিত) সংগ্রহ করে যা আপনি অপারেশন করতে পারবেন collection ব্যবহারকারীদের সারণিতে জিজ্ঞাসা করার জন্য এটি ব্যবহারকারীর ডেটা ম্যাপার ব্যবহার করে তবে এটি ডোমেন মডেল ব্যবহারকারীর কাছে বিমূর্ত হয়ে যায় ।

সংগ্রহস্থলের প্রয়োগ প্যাটার্ন প্রকার ডেটা অ্যাক্সেস লেয়ার আরেকটি হল ডাটা এক্সেস অবজেক্টস শুধুমাত্র পার্থক্য সংগ্রহস্থলের প্রয়োগ হয়েছে মোট রুট বৈশিষ্ট্য

Comments

সংগ্রহস্থল এবং ডিএও নিদর্শনগুলির মধ্যে পার্থক্য রয়েছে, ডিএও হ'ল সাধারণ তথ্য অ্যাক্সেস, সমস্ত একই ধরণের বস্তুর সংগ্রহের অধ্যবসায়ের জন্য সংগ্রহস্থল। অর্থাৎ সমস্ত সংগ্রহস্থলের একই ইন্টারফেস থাকতে হবে (অ্যারে বা তালিকার মতো)। পদ্ধতি অন্য রাজা নেই সংগ্রহস্থলের প্রয়োগ অন্তর্গত। ডিএও নিম্ন স্তরের, সংগ্রহস্থল ডিএও ব্যবহার করতে পারে। প্রায়শই প্রোগ্রামাররা (বিশেষত পিএইচপি) ডিএও হিসাবে সংগ্রহশালা ব্যবহার করে তবে এটি সঠিক নয়।

— xmedeko