ডেটা অবজেক্টের জন্য নির্ভরতা ইনজেকশন ব্যবহার করবেন?

11

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

Class DO{
    DO(){
        DataObject2List = new List<DO2>();
    }

    public string Field1;
    public string Field2;
    public List<DO2> DataObject2List;
}

Class DO2{
    public DateTime Date;
    public double Value;
}

c# dependency-injection class-design

— sooprise
সূত্র

"ডেটা অবজেক্ট" বলতে আসলে কী বোঝ? এটি কোনও স্ট্যান্ডার্ড টার্ম নয়। আপনি কি কোনও ডিটিও সম্পর্কে কথা বলছেন বা আপনি কোনও পদ্ধতি ছাড়াই কোনও শ্রেণীর (যেমন কোনও ডোমেন মডেলের বিশেষত বিরক্তিকর অংশ) উল্লেখ করছেন? দুজনের মধ্যে বিশাল পার্থক্য রয়েছে।

— অ্যারোনআট

অবশ্যই, আমার অর্থ নেই কেবল একটি ক্লাস যার কোনও পদ্ধতি নেই, এমন একটি শ্রেণি যা কেবল ডেটা সঞ্চয় করে। যদি ডেটা অবজেক্টটি এর জন্য সঠিক শব্দটি না হয়, তবে সেখানে একটি রয়েছে, বা এটি কেবল কোনও পদ্ধতি ছাড়াই একটি ক্লাস বলা হয়?

— sooprise

@ এসোপ্রাইজ এটি একটি ভাল প্রশ্ন। ভাল চিন্তা.

— ম্যাথিউ রোডাটাস

@ এসোসপ্রাইজ সম্ভবত আমার উত্তরটি বেস না। আপনি কোথায় সিআরইউডি পদ্ধতি রাখবেন? একটি পৃথক ডেটা অ্যাক্সেস ক্লাসে যা ডেটা অবজেক্টগুলিকে নিয়ে যায় এবং সেগুলি একটি ডেটাবেস টেবিলটিতে চালিয়ে যায়? অর্থাৎ ডেটাঅ্যাক্সেস.ক্রেট করুন (<ডেটাঅবজেক্ট>)?

— ম্যাথিউ রডাটাস

1

@ ম্যাথহে, এটি একটি ডেটা অ্যাক্সেস অবজেক্ট হবে - যদি এটি আসলে ওপি যা বলছে তা যদি হয় তবে তা মোটেই পরিষ্কার নয়। আধুনিক বাস্তবায়নগুলি যেকোন উপায়ে এই প্যাটার্ন থেকে সরে যাওয়ার ঝোঁক থাকে, সংগ্রহস্থল এবং / অথবা কাজের ইউনিটগুলির উপর নির্ভর করে।

— অ্যারোনআউট

7

আপনি এখানে ব্যবহার করছেন এমন কয়েকটি পরিভাষার একটি ব্যাখ্যা বলতে চাই, বিশেষত "নির্ভরতা" এবং "নির্ভরতা ইনজেকশন"।

নির্ভরতা:

একটি "নির্ভরতা" সাধারণত একটি জটিল অবজেক্ট যা কিছু কার্যকারিতা সম্পাদন করে যা অন্য শ্রেণীর উপর নির্ভর করতে হতে পারে। কিছু ক্লাসিক উদাহরণগুলি কোনও লগার বা একটি ডেটাবেস অ্যাকসেসর বা এমন কিছু উপাদান যা ব্যবসায়ের যুক্তির একটি নির্দিষ্ট অংশকে প্রক্রিয়া করে।

একটি ডেটা শুধুমাত্র একটি DTO অথবা একটি মান বস্তু মত বস্তু সাধারণত, একটি "নির্ভরতা" বলা নেই যেহেতু তারা কিছু প্রয়োজনীয় ফাংশন সঞ্চালন না।

একবার তা এই ভাবে তাকান, আপনি কি আপনার উদাহরণে করছেন ( রচনাDO একটি তালিকা সঙ্গে বস্তুর D02কন্সট্রাকটর মাধ্যমে বস্তু) "dependecy ইনজেকশন" সব না বিবেচনা করা উচিত। এটি কেবল একটি সম্পত্তি সেট করছে। এটি আপনি নির্ধারক বা অন্য কোনও উপায়ে সরবরাহ করেছেন কিনা তা আপনার উপর নির্ভর করে, তবে কেবল এটি নির্মাণকারীর মাধ্যমে পাস করা নির্ভরতা ইনজেকশন তৈরি করে না।

নির্ভরতা ইনজেকশন:

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

নির্ভরতাটিকে এইভাবে ইনজেকশন করা DOবস্তুটিকে আরও নমনীয় করে তোলে , যেহেতু প্রতিটি পৃথক প্রসঙ্গ DOবস্তুর কাছে ইন্টারফেসের নিজস্ব বাস্তবায়ন সরবরাহ করতে পারে । (ইউনিট পরীক্ষা চিন্তা করুন।)

— এরিক কিং
সূত্র

7

আমি প্রশ্নের মধ্যে বিভ্রান্তি কাটাতে আমার যথাসাধ্য চেষ্টা করতে যাচ্ছি।

প্রথমত, "ডেটা অবজেক্ট" অর্থবোধক শব্দ নয়। যদি এই অবজেক্টের একমাত্র নির্ধারিত বৈশিষ্ট্যটি হ'ল এর কোনও পদ্ধতি নেই তবে এটির অস্তিত্ব থাকা উচিত নয় । একটি কার্যকর আচরণ-কম অবজেক্টের নিম্নোক্ত উপশ্রেণীশ্রেণীতে অন্তত একটিতে ফিট হওয়া উচিত:

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

আপনি কোনও সত্তা অবজেক্ট বা "ব্যবসায়িক বস্তু" সম্পর্কেও ভাবতে পারেন , এবং এই ক্ষেত্রে আপনি নির্ভরতা ইনজেকশনটিকে সমর্থন করতে চান, তবে আপনি যেভাবে ভাবেন বা যে কারণে আপনি ভাবেন সেভাবে নয়। এটি ব্যবহারকারীর কোডের সুবিধার জন্য নয় , এটি কোনও সত্তা পরিচালক বা ওআরএমের সুবিধার্থে, যা নিঃশব্দে এমন একটি প্রক্সি ইনজেক্ট করবে যা এটি কোয়েরি বোঝার বা অলস লোডিংয়ের মতো অভিনব জিনিস করতে বাধা দেয়।

এর মধ্যে আপনি সাধারণত ইনজেকশনের জন্য কনস্ট্রাক্টর সরবরাহ করেন না ; পরিবর্তে, আপনাকে কেবল সম্পত্তিটি ভার্চুয়াল তৈরি করতে হবে এবং একটি বিমূর্ত প্রকার (যেমন IList<T>পরিবর্তে List<T>) ব্যবহার করতে হবে। বাকী অংশগুলি পর্দার আড়ালে ঘটে এবং কেউই বুদ্ধিমানের হয় না।

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

পুনরাবৃত্তি করতে:

"ডেটা অবজেক্টস" তৈরি করবেন না।
যদি আপনাকে অবশ্যই একটি "ডেটা অবজেক্ট" তৈরি করতে হয়, তবে নিশ্চিত হয়ে নিন যে এর স্পষ্টভাবে সংজ্ঞায়িত উদ্দেশ্য রয়েছে । সেই উদ্দেশ্যটি আপনাকে ডিআই উপযুক্ত কিনা তা জানাবে tell এমন কোনও জিনিস যা প্রথম স্থানে থাকা উচিত নয় সে সম্পর্কে কোনও অর্থবহ নকশা সংক্রান্ত সিদ্ধান্ত নেওয়া অসম্ভব।

ফিন।

— Aaronaught
সূত্র

0

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

সত্যিই, আপনি এখানে কোন নির্ভরতা ইনজেকশন করবেন?

— স্কট হুইটলক
সূত্র

আমি তার উত্তর দিয়েছি এমন একটি অন্য প্রশ্নে আমি মনে করি যে প্রশ্নটি অন্তর্ভুক্ত সিআরইউডি অপারেশন সহ একটি ডেটা অবজেক্টকে বোঝায়। কীভাবে / কোথায় ডাটা অবজেক্টের মধ্যে ডাটাবেস নির্ভরতা ইনজেকশন করা হয়? পদ্ধতিগুলিতে? কনস্ট্রাক্টরে? অন্য কিছু উপায়? অনুমানটি হ'ল নির্ভরতাগুলি পদ্ধতিগুলির মূল অংশে লুকানো উচিত নয় - যা ডাটা অবজেক্ট থেকে ডেটাবেস নির্ভরতা আলাদা করতে অক্ষম করে যাতে ডেটা অবজেক্টটি ইউনিট পরীক্ষা করা যায়।

— ম্যাথু রোডাটাস

@ ম্যাথো রোদাতাস - আমি দেখছি। হ্যাঁ, সেক্ষেত্রে আপনার দুটি পছন্দ রয়েছে: অধ্যবসায় পরিষেবাটি ইনজেকশন করুন বা অন্য শ্রেণি তৈরি করুন DOPersisterযা কীভাবে অবিচল থাকতে হবে DOএবং কীভাবে এটি কেবলমাত্র কঠোরভাবে ডেটা-অবজেক্ট অবজেক্ট (আমার মতে আরও ভাল) রাখতে হবে তা জানে create পরবর্তী ক্ষেত্রে, DOPersisterডাটাবেস নির্ভরতা ইনজেকশন করা হবে।

— স্কট হুইটলক

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

— ম্যাথু রোডাটাস

0

যেহেতু এটি ডেটা অ্যাক্সেস লেয়ারের একটি ডেটা অবজেক্ট তাই এটি সরাসরি একটি ডাটাবেস পরিষেবার উপর নির্ভর করে। আপনি কনস্ট্রাক্টরের জন্য একটি ডাটাবেস সার্ভিস নির্দিষ্ট করতে পারেন:

DataObject dataObject = new DataObject(new DatabaseService());
dataObject.Update();

তবে, ইঞ্জেকশনটি কনস্ট্রাক্টরে থাকতে হবে না। বিকল্পভাবে, আপনি প্রতিটি CRUD পদ্ধতির মাধ্যমে নির্ভরতা সরবরাহ করতে পারেন। আমি এই পদ্ধতির আগেরটির চেয়ে পছন্দ করি কারণ আপনার ডেটা অবজেক্টটি এটি জানা দরকার না যতক্ষণ না আপনি আসলে এটি চালিয়ে যাওয়ার প্রয়োজন না থাকে।

DataObject dataObject = new DataObject();
dataObject.Update(new DatabaseService());

আপনি অবশ্যই CRUD পদ্ধতিতে নির্মাণটি আড়াল করতে চান না !

public void Update()
{
    // DON'T DO THIS!
    using (DatabaseService dbService = new DatabaseService())
    {
        ...
    }
}

বিকল্প বিকল্প হ'ল একটি অতিশ্রয়ী বর্গ পদ্ধতির মাধ্যমে ডেটাবেসস সার্ভিস নির্মাণ করা।

public void Update()
{
    // GetDatabaseService() is protected virtual, so in unit testing
    // you can subclass the Data Object and return your own
    // MockDatabaseService.
    using (DatabaseService dbService = GetDatabaseService())
    {
        ...
    }
}

একটি চূড়ান্ত বিকল্প হ'ল সিঙ্গলটন-স্টাইলের সার্ভিস লোকেশন ব্যবহার করা। যদিও আমি এই বিকল্পটি অপছন্দ করি, এটি ইউনিট পরীক্ষামূলক।

public void Update()
{
    // The ServiceLocator would not be a real singleton. It would have a setter
    // property so that unit tests can swap it out with a mock implementation
    // for unit tests.
    using (DatabaseService dbService = ServiceLocator.GetDatabaseService())
    {
        ...
    }
}

— ম্যাথু রোডাটাস
সূত্র