নির্ভরতা ইনজেকশন বনাম কারখানার প্যাটার্ন


496

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

একবার কেউ আমাকে বলেছিল যে আপনি এটি কীভাবে ব্যবহার করেন এটি একটি পার্থক্য করে!

আমি একবার সমস্যার সমাধানের জন্য স্ট্রাকচারম্যাপ একটি ডিআই কনটেইনার ব্যবহার করেছি , পরে আমি এটি একটি সাধারণ কারখানার সাথে কাজ করার জন্য আবার ডিজাইন করেছি এবং স্ট্রাকচারম্যাপের রেফারেন্সগুলি সরিয়েছি।

কেউ আমাকে বলতে পারেন যে তাদের মধ্যে পার্থক্য কী এবং কোথায় কী ব্যবহার করা যায়, এখানে সেরা অনুশীলনটি কী?


21
এই দুটি পদ্ধতির একে অপরকে প্রশংসা করতে পারে না: কারখানার ক্লাস ইনজেক্ট করতে নির্ভরতা ইনজেকশন ব্যবহার করে?
রিচার্ড ইভ

20
সত্যিই খুব সুন্দর হবে যদি এই প্রশ্নের কোনও কোড সহ উত্তর থাকে! আমি এখনও দেখছি না যে ডিআই তৈরির জন্য কোনও কারখানার ব্যবহার থেকে কীভাবে উপকারী / আলাদা হবে? আপনাকে কোন কারখানা / শ্রেণীর আবশ্যক / বাস্তবায়ন তৈরি হয়েছে তা পরিবর্তন করতে কেবল সেই এক লাইনটি প্রতিস্থাপন করতে হবে?
জিদান

2
@ গিদিওন কি আপনাকে আপনার অ্যাপ্লিকেশন তৈরি করতে বাধ্য করবে না, বা কমপক্ষে ফ্যাক্টরি ক্লাসযুক্ত মডিউলটি তৈরি করবে?
লিজেরজিক-অ্যাসিড

1
পছন্দ করুন সেই মন্তব্যের পরে ডিআই-তে একটি দীর্ঘ গবেষণা করেছে এবং এখন আমি বুঝতে পেরেছি ডিআই ফ্যাক্টরি পদ্ধতিটি একধাপ এগিয়ে নিয়ে যায়।
জিদোন

1
এই দুর্দান্ত উত্তরটি দেখুন: স্ট্যাকওভারফ্লো / প্রশ্নগুলি / 4985455/… - তিনি এটি খুব ভাল শব্দ করেন এবং কোডের নমুনা সরবরাহ করেন।
লুইস পেরেজ

উত্তর:


292

কারখানাটি ব্যবহার করার সময় আপনার কোডটি এখনও অবজেক্ট তৈরির জন্য দায়বদ্ধ। ডিআই দ্বারা আপনি সেই দায়িত্ব অন্য শ্রেণি বা ফ্রেমওয়ার্কে আউটসোর্স করেন যা আপনার কোড থেকে পৃথক।


172
ডিআই প্যাটার্নটির জন্য কোনও ফ্রেমওয়ার্কের প্রয়োজন হয় না। আপনি নিজে ডিআই করেন এমন কারখানাগুলি লিখে ডিআই করতে পারেন। ডিআই ফ্রেমওয়ার্কগুলি কেবল এটি সহজ করে তোলে।
এসকো লুন্তটোলা

28
@ পার্পিটুয়ালকোডার - ধন্যবাদ @ এস্কো - কিছু উন্নত তৃতীয় পক্ষের লাইব্রেরি অর্থ শব্দের কাঠামোয় ধরা পড়বেন না।
উইলকোডেজাভফুফুড

4
+1 @ উইলকোড ধন্যবাদ! সুতরাং পরিবর্তে আপনার কনফিগারেশন / এক্সএমএল ফাইলগুলি পরিবর্তন করতে হবে। আমি দেখি. উইকি লিঙ্ক en.wikedia.org/wiki/… কারখানার প্যাটার্নটি হিসাবে সংজ্ঞায়িত করেছেManually-Injected Dependency
gideon

5
আমি এক্সএমএল এর 1 লাইন কোড বনাম 1 লাইন পরিবর্তন করার সুবিধা পাচ্ছি না। আপনি বিস্তারিত বলতে পারেন?
রাফায়েল আইং

1
"ডিআই" কে "ফ্যাক্টরি" দিয়ে প্রতিস্থাপনের ওপি উত্তরটি পুনরাবৃত্তি করুন, তবুও তা বোঝা যায়।
এডসন মদিনা

219

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


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

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

1
চমৎকার উত্তর. অনেকে এই প্রশ্নটির সাথে বিভ্রান্ত করছেন: "আমার কোন প্যাটেনগুলি নির্বাচন করা উচিত?" আসলে, ডিজাইনের নিদর্শনগুলি উপযুক্ত পরিস্থিতিতে সমস্যা সমাধানের একমাত্র উপায়। আপনার কী ডিজাইনের প্যাটার্নটি ব্যবহার করা উচিত তা যদি আপনি জানেন না বা "প্যাটার্নটি আমার কোথায় প্রয়োগ করা উচিত?" তাহলে আপনার এই মুহুর্তে দরকার নেই।
বেনি

2
আমি মনে করি ফ্যাক্টরি প্যাটার্নটি আইওসি (ডিআই নয়) বাস্তবায়নের একটি সরঞ্জাম say দয়া করে মনে রাখবেন যে ডিআই হ'ল আইওসি
হুমান বাহরাইনি

185

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

যন্ত্রাংশ নিজেই ইনস্ট্যান্ট করার পরিবর্তে একটি গাড়ি যে অংশগুলির কাজ করতে হবে তার জন্য জিজ্ঞাসা করে।

class Car
{
    private Engine engine;
    private SteeringWheel wheel;
    private Tires tires;

    public Car(Engine engine, SteeringWheel wheel, Tires tires)
    {
        this.engine = engine;
        this.wheel = wheel;
        this.tires = tires;
    }
}

কারখানা

একটি সম্পূর্ণ অবজেক্ট তৈরি করতে টুকরোগুলি একসাথে রাখে এবং কলার থেকে কংক্রিটের প্রকারটি লুকায়।

static class CarFactory
{
    public ICar BuildCar()
    {
        Engine engine = new Engine();
        SteeringWheel steeringWheel = new SteeringWheel();
        Tires tires = new Tires();
        ICar car = new RaceCar(engine, steeringWheel, tires);
        return car;
    }   
}

ফলাফল

যেমন আপনি দেখতে পাচ্ছেন, কারখানাগুলি এবং ডিআই একে অপরের পরিপূরক।

static void Main()
{
     ICar car = CarFactory.BuildCar();
     // use car
}

আপনি স্বর্ণলোকস এবং তিনটি ভালুকের কথা মনে আছে? ঠিক আছে, নির্ভরতা ইনজেকশন এ জাতীয় ধরণের। একই জিনিসটি করার জন্য এখানে তিনটি উপায়।

void RaceCar() // example #1
{
    ICar car = CarFactory.BuildCar();
    car.Race();
}

void RaceCar(ICarFactory carFactory) // example #2
{
    ICar car = carFactory.BuildCar();
    car.Race();
}

void RaceCar(ICar car) // example #3
{
    car.Race();
}

উদাহরণ # 1 - এটি সবচেয়ে খারাপ কারণ এটি সম্পূর্ণ নির্ভরতা লুকায় ides আপনি যদি পদ্ধতিটিকে একটি কালো বাক্স হিসাবে দেখেন তবে আপনার কোনও গাড়ী প্রয়োজন হবে তা ধারণা নেই।

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

উদাহরণ # 3 - এটি আদর্শ কারণ পদ্ধতিটি ঠিক কী প্রয়োজন তা জিজ্ঞাসা করে । খুব বেশি বা খুব সামান্যও নয়। শুধু মককারস তৈরি করতে আমাকে মককারফ্যাক্টরি লিখতে হবে না, আমি সরাসরি মকটি পাস করতে পারি It এটি সরাসরি এবং ইন্টারফেসটি মিথ্যা নয়।

মিসকো হেভির এই গুগল টেক টকটি আশ্চর্যজনক এবং আমি যা থেকে আমার উদাহরণটি পেয়েছি তার ভিত্তি এটি। http://www.youtube.com/watch?v=XcT4yYu_TTs


1
কারখানার প্যাটার্নটি ডিআই হিসাবে ইনজেকশন করা হয়।
মঙ্গেশ পিম্পলকর

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

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

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

3
@ ডিগোমেন্ডেস আপনি যা বর্ণনা করছেন তা হ'ল একটি ফ্রেমওয়ার্ক যা ডিআইকে স্বয়ংক্রিয় করে তোলে। সার্ভিস লোকেটার হিসাবে আপনি এটি কল করবেন আপনার জন্য ডিআই করে। আমি যা দেখছি তা হ'ল প্যাটার্নটি যা কোনও অভিনব ফ্রেমওয়ার্কের প্রয়োজন হয় না। দেখুন stackoverflow.com/a/140655/1160036 , অথবা en.wikipedia.org/wiki/... : "[অবকাঠামো তালিকা] সমর্থন নির্ভরতা ইনজেকশন কিন্তু নির্ভরতা ইনজেকশন তা করার প্রয়োজন নেই"। এছাড়াও, "একটি ইনজেকশন হ'ল নির্ভর অবজেক্টের উপর নির্ভরতা কেটে যাওয়া"। আপনি একটি সুন্দর সহজ ধারণা জটিলতা শেষ।
দেশপারটার

50

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

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

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

কারখানার নকশার প্যাটার্নটি বেশ পুরানো (সফটওয়্যারের নিরিখে) এবং কিছু সময়ের জন্য রয়েছে। স্থাপত্য নিদর্শন আইওসির সাম্প্রতিক জনপ্রিয়তার কারণে এটির পুনরুত্থান হচ্ছে।

আমি ধারণা করি এটি আইওসি ডিজাইনের ধরণগুলির ক্ষেত্রে আসে: ইনজেক্টরগুলি ইনজেকশন দেয়, লোকেটারগুলি লোকেটেড হয় এবং কারখানাগুলি রিফ্যাক্টর হয়।


3
এটি সেরা উত্তর ... অন্য উত্তরগুলি হয় আইওসির উল্লেখ না করে বা ডিআইও-র একটি রূপ এটি স্বীকৃতি দেয় না।
হুমান বাহরিনী

ধন্যবাদ, আমি যখন প্রথম আইওসি নিয়ে পড়াশোনা করেছি তখন প্রায় চিৎকার করেছিলাম যে এটি কারখানার প্যাটার্নের অন্যরকম রূপ, দেখা গেছে তারা সত্যই একে অপরের সাথে সমান
হার্ভে লিন

40

নির্ভরতা ইনজেকশন দিয়ে সমাধান করা সহজ এমন সমস্যা রয়েছে যা কারখানার স্যুট দিয়ে এত সহজে সমাধান করা যায় না।

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

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

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


26

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


22

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

থেকে: http://tutorials.jenkov.com/d dependency- inication/ d dependency-inication-containers.html


15

আমি বিশ্বাস করি ডিআই কারখানাগুলিতে এক প্রকার বিমূর্ত স্তর, তবে তারা বিমূর্ততার বাইরেও সুবিধা সরবরাহ করে। সত্যিকারের কারখানাটি কীভাবে একক প্রকারটি ইনস্ট্যান্ট করে এটি কনফিগার করতে পারে তা জানে। একটি ভাল ডিআই লেয়ার কনফিগারেশনের মাধ্যমে বিভিন্ন ধরণের ইনস্ট্যান্টিয়েট ও কনফিগার করার ক্ষমতা সরবরাহ করে।

স্পষ্টতই, কয়েকটি সাধারণ ধরণের একটি প্রকল্পের জন্য যা তাদের নির্মাণে তুলনামূলকভাবে স্থিতিশীল ব্যবসায়ের যুক্তি প্রয়োজন, কারখানার প্যাটার্নটি বোঝা, বাস্তবায়ন করা এবং ভালভাবে কাজ করা সহজ।

ওটিওহ, যদি আপনার এমন অসংখ্য প্রকল্প রয়েছে যার বাস্তবায়নগুলি আপনি প্রায়শই পরিবর্তনের প্রত্যাশা করেন, ডিআই আপনাকে আপনার কারখানাগুলি পুনরায় সংকলন না করে রানটাইমে এটি করার জন্য তার কনফিগারেশনের মাধ্যমে নমনীয়তা দেয়।


14

তত্ত্ব

দুটি বিষয় বিবেচনা করার জন্য গুরুত্বপূর্ণ:

  1. যিনি বস্তু তৈরি করেন

    • [কারখানা]: আপনাকে লিখতে হবে কীভাবে অবজেক্ট তৈরি করা উচিত। আপনার পৃথক কারখানার শ্রেণি রয়েছে যাতে সৃষ্টি যুক্তি রয়েছে।
    • [নির্ভরতা ইনজেকশন]: ব্যবহারিক ক্ষেত্রে বহিরাগত ফ্রেমওয়ার্ক দ্বারা সম্পন্ন হয় (উদাহরণস্বরূপ জাভাতে যা বসন্ত / এজেবি / গুইস হবে)। ইনজেকশনটি নতুন ম্যাজিকের স্পষ্টতূপে তৈরি না করে "ম্যাজিকালি" হয়
  2. এটি কী ধরণের জিনিস পরিচালনা করে:

    • [কারখানা]: সাধারণত রাষ্ট্রীয় অবজেক্ট তৈরির জন্য দায়ী
    • [নির্ভরতা ইনজেকশনস] স্টেটলেস অবজেক্ট তৈরির সম্ভাবনা বেশি

একক প্রকল্পে কারখানা এবং নির্ভরতা ইঞ্জেকশন উভয়ই কীভাবে ব্যবহার করতে হয় তার ব্যবহারিক উদাহরণ

  1. আমরা যা তৈরি করতে চাই

অর্ডার তৈরির জন্য অ্যাপ্লিকেশন মডিউল যা অর্ডারলাইন বলে একাধিক এন্ট্রি রয়েছে।

  1. স্থাপত্য

ধরে নেওয়া যাক আমরা নিম্নলিখিত স্তর আর্কিটেকচার তৈরি করতে চাই:

এখানে চিত্র বর্ণনা লিখুন

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

  1. ডোমেন স্তর এবং কারখানার ব্যবহার

ডাটাবেসে থাকা সত্তা হ'ল অর্ডার এবং অর্ডারলাইন। অর্ডারে একাধিক অর্ডারলাইন থাকতে পারে। অর্ডার এবং অর্ডারলাইন এর মধ্যে সম্পর্ক

এখন আসে গুরুত্বপূর্ণ ডিজাইনের অংশ। এর বাইরে থাকা মডিউলগুলি তাদের নিজেরাই অর্ডারলাইনগুলি তৈরি এবং পরিচালনা করতে হবে? না। অর্ডার লাইন কেবল তখনই উপস্থিত থাকতে হবে যখন আপনার সাথে অর্ডার যুক্ত থাকে। আপনি যদি বাইরের ক্লাসে অভ্যন্তরীণ বাস্তবায়নটি আড়াল করতে পারেন তবে সবচেয়ে ভাল হবে।

তবে অর্ডারলাইন সম্পর্কে জ্ঞান ছাড়াই অর্ডার কীভাবে তৈরি করবেন?

কারখানা

যে কেউ নতুন অর্ডার তৈরি করতে চান তিনি অর্ডারফ্যাক্টরি ব্যবহার করেছেন (যা আমরা অর্ডারটি কীভাবে তৈরি করি তার বিশদটি গোপন করে)।

এখানে চিত্র বর্ণনা লিখুন

এটি IDE এর অভ্যন্তরে কেমন দেখায় ts domainপ্যাকেজের বাইরের ক্লাসগুলি OrderFactoryভিতরে কন্সট্রাক্টরের পরিবর্তে ব্যবহার করবেOrder

  1. নির্ভরতা ইনজেকশন ডিপেন্ডেন্সি ইনজেকশনটি সাধারণত স্টেটহীন স্তরগুলির যেমন সংগ্রহস্থল এবং পরিষেবাগুলির সাথে বেশি ব্যবহৃত হয়।

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

এখানে চিত্র বর্ণনা লিখুন


আপনি কি এই পরিষ্কার করতে পারেন? [Factory]: Usually responsible for creation of stateful objects [Dependency Injections] More likely to create stateless objectsআমি বুঝতে পারি না কেন
মাকসিম দিমিত্রিভ

2
রাষ্ট্রীয় অবজেক্টগুলি সম্ভবত অ্যাপ্লিকেশনটির ডোমেন স্তরে থাকবে যেখানে আপনি আপনার ডেটাবেজে ডেটাবেজে ম্যাপ করেন যেখানে আপনি সাধারণত সেখানে নির্ভরতা ইনজেকশন ব্যবহার করেন না। কারখানার প্রায়শই জটিল
সামগ্রীর

12

আমি জানি এই প্রশ্নটি পুরানো তবে আমি আমার পাঁচটি সেন্ট যুক্ত করতে চাই,

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

আসলে, যদি আপনি উদাহরণস্বরূপ বসন্ত ব্যবহার করেন তবে আপনার কাছে রিসোর্সিং রিসোর্স (ডিআই) বা এই জাতীয় কিছু করার বিকল্প রয়েছে:

MyBean mb = ctx.getBean("myBean");

এবং তারপরে কিছু করতে 'এমবি' উদাহরণটি ব্যবহার করুন। এটি কি কোনও কারখানার কল নয় যা আপনাকে একটি উদাহরণ ফিরিয়ে দেবে ??

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

এবং আপনি যদি আমার কাছে আমার মতামত জানতে চান (এবং আমি জানি আপনি করেননি), আমি বিশ্বাস করি যে ডিআই একই কাজ করে তবে কেবল উন্নয়নের ক্ষেত্রে আরও জটিলতা যুক্ত করে, কেন?

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

কিন্তু ... সেই প্রতিশ্রুতি সম্পর্কে কী যে আপনি যে অবজেক্টটি ব্যবহার করছেন তা বাস্তবায়ন করতে হবে না? pfft! গম্ভীরভাবে? আপনি যখন এই জাতীয় মতামত ব্যবহার করেন ... আপনি কি একইরকম হন না যা প্রয়োগটি লেখেন ?? এবং এমনকি যদি আপনি না করেন তবে আপনি প্রায় সবসময়ই এটি দেখতে যাচ্ছেন যা বাস্তবায়ন কী করার কথা বলে তা কী করে ??

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

আসলে, আমি দেখতে পাচ্ছি যে কোনও এফপি বা ডিআই পদ্ধতির একমাত্র আসল ব্যবসায়ের অ্যাপ্লিকেশনটি হ'ল রানটাইম ব্যবহারের সময় যদি আপনার প্রয়োগগুলি পরিবর্তন করা দরকার তবে তা কমপক্ষে আমার জানা ফ্রেমওয়ার্কগুলি আপনাকে এটি করতে দেয় না, আপনাকে ছেড়ে যেতে হবে বিকাশের সময় কনফিগারেশনে নিখুঁত সবকিছু আপনার যদি অন্য পদ্ধতির প্রয়োজন হয়।

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

MyBean mb = MyBeanForEntreprise1(); //In the classes of the first enterprise
MyBean mb = MyBeanForEntreprise2(); //In the classes of the second enterprise

এই হিসাবে একই:

@Autowired MyBean mbForEnterprise1; //In the classes of the first enterprise
@Autowired MyBean mbForEnterprise2; //In the classes of the second enterprise

এবং এই:

MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise1"); //In the classes of the first enterprise
MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise2"); //In the classes of the second enterprise

ক্লাস বা কনফিগারেশন ফাইল যাই হোক না কেন আপনাকে আপনার অ্যাপ্লিকেশনটিতে কিছু পরিবর্তন করতে হবে, তবে আপনাকে এটি পুনরায় চালু করতে হবে।

এই জাতীয় কিছু করা ভাল হবে না:

MyBean mb = (MyBean)MyFactory.get("mb"); 

এবং এইভাবে, আপনি লগইন হওয়া ইউজার এন্টারপ্রাইজের উপর নির্ভর করে রানটাইমে সঠিক প্রয়োগের জন্য কারখানার কোড সেট করেছেন ?? এখন এটি সহায়ক হবে। আপনি কেবলমাত্র নতুন ক্লাসগুলির সাথে একটি নতুন জার যুক্ত করতে পারেন এবং নিয়মগুলি এমনকি রানটাইম সময়েও সেট করতে পারেন (বা আপনি যদি এই বিকল্পটি উন্মুক্ত রেখে দেন তবে একটি নতুন কনফিগার ফাইল যুক্ত করুন), বিদ্যমান ক্লাসে কোনও পরিবর্তন নেই। এটি একটি ডায়নামিক কারখানা হবে!

প্রতিটি এন্টারপ্রাইজের জন্য দুটি কনফিগারেশন লেখার চেয়ে আরও কার্যকর হতে পারে না, এবং এমনকি প্রতিটিটির জন্য দুটি আলাদা অ্যাপ্লিকেশন থাকতে পারে ??

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

যাইহোক, যদি আপনি আমাকে হত্যা করার জন্য মন্তব্য বিভাগ খোলা।


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

6

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


4

নির্ভরতা ইনজেকশন সহ ক্লায়েন্টের নিজের উপর নির্ভরশীলতা নেওয়ার প্রয়োজন নেই, এটি সমস্ত আগে থেকেই প্রস্তুত।

কারখানাগুলির সাথে, কারও কাছে কল করতে হবে যে উত্পন্ন জিনিসগুলি তাদের প্রয়োজনীয় জায়গায় নিয়ে যেতে হবে।

পার্থক্যটি মূলত এই এক লাইনেই রয়েছে যেখানে কারখানাকে কল করা এবং নির্মিত বস্তু আনতে কাজ করা হয়।

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


3

আমি ডিআই সম্পর্কে পড়ার সাথে সাথে আমার একই প্রশ্ন ছিল এবং এই পোস্টে শেষ হয়েছিল। সুতরাং অবশেষে এটি আমি বুঝতে পেরেছি তবে ভুল হলে দয়া করে আমাকে সংশোধন করুন।

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

ছোট রাজ্যের পরিচালনা সংস্থা হ'ল "কারখানাগুলি"

বড় সরকার হ'ল "নির্ভরতা ইনজেক্টর"।


1
সুতরাং যখন একটি কোডসাইডার আগের ছোট সরকারকে এখন বড় হতে পারে? কি পরিমাপ দ্বারা?
বন্দী

3

একটি বাস্তব উদাহরণে দুটি (এবং অন্যান্য) পদ্ধতির তুলনা করার জন্য আপনি এই লিঙ্কটি একবার দেখতে পারেন ।

মূলত, যখন প্রয়োজনীয়তা পরিবর্তন হয়, আপনি ডিআই এর পরিবর্তে কারখানাগুলি ব্যবহার করেন তবে আপনি আরও কোড সংশোধন করবেন।

এটি ম্যানুয়াল ডিআই এর সাথেও বৈধ (যেমন কোনও বাহ্যিক কাঠামো নেই যা আপনার সামগ্রীর উপর নির্ভরশীলতা সরবরাহ করে তবে আপনি প্রতিটি নির্মাণকারীকে এগুলি পাস করেন)।


3

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

একবার কেউ আমাকে বলেছিল যে আপনি এটি কীভাবে ব্যবহার করেন এটি একটি পার্থক্য করে!

যথাযথভাবে। 90% ক্ষেত্রে আপনি কারখানা বা ডিআই ব্যবহার করে অবজেক্টের রেফারেন্স পেতে পারেন এবং সাধারণত আপনি শেষ পর্যন্ত শেষ করেন। অন্য 10% ক্ষেত্রে কারখানাটি ব্যবহার করা কেবল সঠিক উপায় । এই ক্ষেত্রে রানটাইম প্যারামিটারগুলিতে ভেরিয়েবল দ্বারা অবজেক্টগুলি প্রাপ্ত করা অন্তর্ভুক্ত। এটার মত:

IWebClient client = factoryWithCache.GetWebClient(url: "stackoverflow.com",
        useCookies: false, connectionTimeout: 120);

এই ক্ষেত্রে clientডিআই থেকে প্রাপ্ত হওয়া সম্ভব নয় (বা কমপক্ষে কিছু কুৎসিত কাজের প্রয়োজন) requires সুতরাং সিদ্ধান্ত নেওয়ার সাধারণ নিয়ম হিসাবে: যদি কোনও রানটাইম গণনা করা পরামিতি ছাড়াই নির্ভরতা অর্জন করা যায় তবে ডিআই-কে অগ্রাধিকার দেওয়া হয়, অন্যথায় কারখানাটি ব্যবহার করুন।


2

আমি বিশ্বাস করি যে ডিআই হ'ল বিনকে কনফিগার করার বা তাত্ক্ষণিক করার একটি উপায়। ডিআইটি বিভিন্ন উপায়ে করা যেতে পারে যেমন কনস্ট্রাক্টর, সেটার-গেটর ইত্যাদি in

মটরশুটি ইনস্ট্যান্ট করার জন্য কারখানার প্যাটার্ন হ'ল অন্য উপায়। এই প্যাটার্নটি মূলত তখন ব্যবহার করা হবে যখন আপনাকে কারখানার নকশার প্যাটার্ন ব্যবহার করে অবজেক্ট তৈরি করতে হবে, কারণ এই প্যাটার্নটি ব্যবহার করার সময় আপনি শিমের বৈশিষ্ট্যগুলি কনফিগার করবেন না, কেবলমাত্র বস্তুকে তাত্ক্ষণিক করে তুলবেন।

এই লিঙ্কটি দেখুন: নির্ভরতা ইনজেকশন


2

Binoj,

আমি মনে করি না আপনাকে অন্যটির থেকে একটি বেছে নিতে হবে।

নির্ভরশীল শ্রেণি বা ইন্টারফেসটিকে কোনও শ্রেণি নির্মাতা বা সেটারে স্থানান্তরিত করার কাজটি ডিআই প্যাটার্ন অনুসরণ করে। আপনি নির্ধারক বা সেটটিতে যে বস্তুটি পাস করবেন তা কারখানার মাধ্যমে প্রয়োগ করা যেতে পারে।

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


2

আমি বিশ্বাস করি, তিনটি গুরুত্বপূর্ণ দিক অবজেক্টগুলি এবং তাদের ব্যবহারকে পরিচালনা করে:
১. ইনস্ট্যান্টেশন (কোনও শ্রেণীর একসাথে যদি প্রাথমিকভাবে থাকে তবে)।
২. ইনজেকশন (যেমন তৈরি হয়েছে তাই) যেখানে এটি প্রয়োজন।
৩. লাইফ সাইকেল ম্যানেজমেন্ট (যেমনটি তৈরি করা হয়েছে)

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

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

কারখানাগুলি ছোট অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত হতে পারে, বড়গুলি কারখানার চেয়ে ডিআই চয়ন করা ভাল।


1

আমার চিন্তা:

ডিপেন্ডেসি ইনজেকশন: কনস্ট্রাক্টরগুলিকে পরামিতি হিসাবে সহযোগীদের পাস করুন। নির্ভরতা ইনজেকশন ফ্রেমওয়ার্ক: কনস্ট্রাক্টরগুলিকে পরামিতি হিসাবে পাস করার জন্য অবজেক্টগুলি তৈরি করার জন্য একটি জেনেরিক এবং কনফিগারযোগ্য কারখানা।


1
হ্যাঁ অবশ্যই. এই প্রশ্নোত্তর মধ্যে Dependency Injection (DI) এর প্রায় সব উল্লেখই এই সংজ্ঞাটির বিপরীতে শব্দটির অপব্যবহার করে। ডিপেন্ডেন্সি ইনজেকশন কনটেইনার (ডিআইসি) হ'ল অবজেক্ট তৈরির জন্য জেনেরিক এবং কনফিগারযোগ্য কারখানা হিসাবে কাজ করা সবচেয়ে সাধারণ কাঠামো।
CXJ

1

ইনজেকশন ফ্রেমওয়ার্কটি কারখানার প্যাটার্নটির একটি বাস্তবায়ন।

এটি আপনার প্রয়োজনীয়তার উপর নির্ভর করে। আপনার যদি কোনও অ্যাপ্লিকেশনটিতে কারখানার প্যাটার্ন বাস্তবায়ন করতে হয়, সম্ভবত আপনার প্রয়োজনীয়তাগুলি সেখানে ইঞ্জেকশন ফ্রেমওয়ার্ক বাস্তবায়নের অগণিত এক দ্বারা পূরণ করা সম্ভব।

আপনার প্রয়োজনীয়তা যদি তৃতীয় পক্ষের ফ্রেমওয়ার্কগুলির কোনওর দ্বারা পূরণ করা না যায় তবে আপনার নিজের সমাধানটি তৈরি করতে হবে। আপনি যত বেশি কোড লিখবেন, আপনাকে তত বেশি কোড বজায় রাখতে হবে। কোড একটি দায় একটি সম্পদ নয়।

কোন প্রয়োগের উপর আপনার ব্যবহারের উচিত সেই যুক্তিগুলি আপনার অ্যাপ্লিকেশনটির আর্কিটেকচারাল প্রয়োজনীয়তা বোঝার মতো মৌলিকভাবে গুরুত্বপূর্ণ নয়।


1

কারখানার নকশার প্যাটার্ন

কারখানার নকশা প্যাটার্ন দ্বারা চিহ্নিত করা হয়

  • একটি ইন্টারফেস
  • বাস্তবায়ন ক্লাস
  • একটি কারখানা

আপনি নীচে হিসাবে নিজেকে প্রশ্ন যখন আপনি কয়েকটি জিনিস পর্যবেক্ষণ করতে পারেন

  • কারখানা কখন বাস্তবায়ন ক্লাসগুলির জন্য বস্তু তৈরি করবে - সময় চালাবে বা সময় সংকলন করবে?
  • আপনি যদি রান সময়ে বাস্তবায়নটি পরিবর্তন করতে চান? - সম্ভব না

এগুলি নির্ভরতা ইনজেকশন দ্বারা পরিচালিত হয়।

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

আপনি নির্ভরশীলতা ইনজেকশন করতে পারেন এমন বিভিন্ন উপায়ে থাকতে পারে। সরলতার জন্য ইন্টারফেস ইনজেকশন দিয়ে যেতে দিন

ডিআই-তে, ধারক প্রয়োজনীয় দৃষ্টান্ত তৈরি করে এবং সেগুলিকে "ইনজেকশন" দেয়।

এভাবে স্থিতিশীল ইনস্ট্যান্টেশন দূর হয়।

উদাহরণ:

public class MyClass{

  MyInterface find= null;

  //Constructor- During the object instantiation

  public MyClass(MyInterface myInterface ) {

       find = myInterface ;
  }

  public void myMethod(){

       find.doSomething();

  }
}

1

একটি মুখের মান থেকে তারা দেখতে একই রকম

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

তবে ... "চাকাটি পুনর্বিবেচনা করবেন না"

আর্কিটেকচারাল দৃষ্টিকোণ থেকে এটি একটি বাধ্যতামূলক স্তর এবং "চাকাটি পুনরায় উদ্ভাবন করবেন না"।

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

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

আপনার সমস্ত কিছু যদি হাতুড়ি হয় তবে সবকিছুই পেরেকের মতো দেখাচ্ছে

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

তবে কোনও বৃহত প্রকল্পের জন্য বা যদি আপনার প্রকল্পটি আরও বড় হয়, আমি আপনাকে উচ্চতর ফ্রেমওয়ার্ক সহ একটি ডিআই লেয়ার রাখার পরামর্শ দিই এবং আপনি যে ডিআই ফ্রেম ব্যবহার করেন তা পরিবর্তনের জন্য জায়গা তৈরি করার পরামর্শ দিন (মেইন অ্যাপে একটি ফেসিড ব্যবহার করুন (ওয়েব অ্যাপ, ওয়েব এপি, ডেস্কটপ তারতম্য.এটি।)।


1

একটি কারখানার সাথে আপনি সম্পর্কিত ইন্টারফেসগুলি গোষ্ঠীভুক্ত করতে পারেন, সুতরাং পাস করা প্যারামিটারগুলি যদি কোনও কারখানায় গোষ্ঠীভুক্ত করা যায় তবে constructor overinjectionএই কোডটি দেখার জন্য এটিও একটি ভাল সমাধান *):

public AddressModelFactory(IAddressAttributeService addressAttributeService,
        IAddressAttributeParser addressAttributeParser,
        ILocalizationService localizationService,
        IStateProvinceService stateProvinceService,
        IAddressAttributeFormatter addressAttributeFormatter)
    {
        this._addressAttributeService = addressAttributeService;
        this._addressAttributeParser = addressAttributeParser;
        this._localizationService = localizationService;
        this._stateProvinceService = stateProvinceService;
        this._addressAttributeFormatter = addressAttributeFormatter;
    }

কনস্ট্রাক্টরটির দিকে তাকান, আপনাকে কেবল IAddressModelFactoryসেখানে পৌঁছাতে হবে, তাই কম পরামিতি *):

 public CustomerController(IAddressModelFactory addressModelFactory,
        ICustomerModelFactory customerModelFactory,
        IAuthenticationService authenticationService,
        DateTimeSettings dateTimeSettings,
        TaxSettings taxSettings,
        ILocalizationService localizationService,
        IWorkContext workContext,
        IStoreContext storeContext,
        ICustomerService customerService,
        ICustomerAttributeParser customerAttributeParser,
        ICustomerAttributeService customerAttributeService,
        IGenericAttributeService genericAttributeService,
        ICustomerRegistrationService customerRegistrationService,
        ITaxService taxService,
        CustomerSettings customerSettings,
        AddressSettings addressSettings,...

আপনি CustomerControllerউত্তীর্ণ অনেকগুলি প্যারামিটারে দেখেন, হ্যাঁ আপনি এটি দেখতে পারেন constructor overinjectionতবে ডিআই কীভাবে কাজ করে এটি। এবং কিছুই কিছুই ভুল হয় না CustomerController

*) কোডটি নোপকমার্স থেকে।


1

সাধারণ কথায় নির্ভরশীলতা ইনজেকশন বনাম কারখানা পদ্ধতিটি যথাক্রমে পুশ বনাম পুল প্রক্রিয়া বোঝায়।

টান মেকানিজম : কারখানার পরোক্ষভাবে কারখানার পদ্ধতির উপর নির্ভরতা থাকে যার পরিবর্তে কংক্রিটের ক্লাসগুলির উপর নির্ভরতা থাকে।

পুশ মেকানিজম : রুট উপাদানটি একটি একক স্থানে সমস্ত নির্ভরশীল উপাদানগুলির সাথে কনফিগার করা যায় এবং এইভাবে উচ্চ রক্ষণাবেক্ষণ এবং আলগা সংযোগ প্রচার করে।

কারখানার পদ্ধতির সাথে দায়বদ্ধতা এখনও ক্লাসের সাথে রয়েছে (যদিও অপ্রত্যক্ষভাবে) নতুন অবজেক্ট তৈরি করতে যেখানে নির্ভরতা ইনজেকশন হিসাবে সেই দায়িত্ব আউটসোর্স করা হয় (যদিও বিমূর্ততা ফাঁস করার ব্যয়ে)


0

আমি মনে করি এগুলি অরথোগোনাল এবং একসাথে ব্যবহার করা যেতে পারে। আমি আপনাকে সম্প্রতি একটি উদাহরণ দিয়ে দেখি যে আমি সম্প্রতি কাজ করে এসেছি:

আমরা জাভাতে স্প্রিং ফ্রেমওয়ার্কটি ডিআই এর জন্য ব্যবহার করছিলাম। একটি সিঙ্গলটন শ্রেণিতে ( Parent) অন্য শ্রেণীর ( Child) নতুন বস্তুগুলি ইনস্ট্যান্ট করতে হত এবং তাদের জটিল সহযোগী ছিল:

@Component
class Parent {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
    }

    void method(int p) {
        Child c = new Child(dep1, dep2, ..., depN, p);
        // ...
    }
}

এই উদাহরণে, কেবলমাত্র তাদের কাছে পাস Parentকরার জন্য DepXদৃষ্টান্তগুলি গ্রহণ করতে হবেChild কন্সট্রাক্টরকে । এটির সাথে সমস্যাগুলি:

  1. Parent আরও জ্ঞান আছে Child চেয়ে থাকতে হবে
  2. Parent এর চেয়ে আরও বেশি সহযোগী রয়েছে
  3. নির্ভরতা যুক্ত করার Childসাথে পরিবর্তন জড়িতParent

আমি যখন বুঝতে পারি যে Factoryএখানে কোনওটি পুরোপুরি ফিট হয়ে যাবে:

  1. এটি Childশ্রেণীর সত্যিকারের পরামিতিগুলি বাদ দিয়ে সমস্তটি লুকিয়ে রাখে byParent
  2. এটি একটি তৈরির জ্ঞানকে encapsulates Child, যা ডিআই কনফিগারেশনে কেন্দ্রীভূত করা যেতে পারে।

এটি সরলীকৃত Parentশ্রেণী এবং ChildFactoryশ্রেণি:

@Component
class Parent {
    // ...
    @Autowired
    Parent(ChildFactory childFactory) {
        this.childFactory = childFactory;
    }

    void method(int p) {
        Child c = childFactory.newChild(p);
        // ...
    }
}

@Component
class ChildFactory {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
        // ...
        this.depN = depN;
    }

    Child newChild(int p) {
        return new Child(dep1, dep2, ..., depN, p);
    }
}

0

আপনি নির্ভরশীলতা ইঞ্জেকশনটি ব্যবহার করেন যখন আপনি ঠিক জানেন যে এই সময়ে আপনার কী ধরণের জিনিস প্রয়োজন। কারখানার প্যাটার্নের ক্ষেত্রে, আপনি কেবল কারখানায় অবজেক্ট তৈরির প্রক্রিয়াটি অর্পণ করেন কারণ আপনার সঠিক ধরণের কী কী জিনিস প্রয়োজন তা আপনি অস্পষ্ট।


-1

আমি উভয়টি বিকাশকারীদের যারা আমার পরে এটি বজায় রাখা প্রয়োজন তাদের আরও পাঠযোগ্যতার সাথে নিয়ন্ত্রণের একটি ইনভার্সন কৌশল তৈরি করতে ব্যবহার করি ।

আমি আমার বিভিন্ন স্তর স্তর (ব্যবসায়, ডেটা অ্যাক্সেস) তৈরি করতে একটি কারখানা ব্যবহার করি।

ICarBusiness carBusiness = BusinessFactory.CreateCarBusiness();

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

এই কাঠামোটি ইতিমধ্যে নিয়ন্ত্রণের বিপরীতমুখী। আমি নির্দিষ্ট অবজেক্ট তৈরির জন্য আর দায়বদ্ধ নই। তবে সহজেই জিনিসগুলি সহজেই পরিবর্তন করতে সক্ষম হতে আপনাকে নির্ভরতা ইনজেকশনটি নিশ্চিত করতে হবে। আপনার নিজস্ব কাস্টম নির্ভরতা ইনজেকশন তৈরি করা হাস্যকর, তাই আমি ityক্য ব্যবহার করি। CreateCarBusiness () এর মধ্যে আমি ityক্যকে সমাধান করতে বলি যে এটি কোন শ্রেণীর অন্তর্ভুক্ত এবং এর জীবনকাল।

সুতরাং আমার কোড কারখানার নির্ভরতা ইনজেকশন কাঠামোটি হ'ল:

public static class BusinessFactory
{
    public static ICarBusiness CreateCarBusiness()
    {
       return Container.Resolve<ICarBusiness>();
    }
}

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

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


-4

আপনি যদি হন তবে নির্ভরতা ইনজেকশন ব্যবহার করা আমার মতে আরও ভাল 1. ২. পরীক্ষার যোগ্যতা হ'ল ডিআই ব্যবহার করা ঠিক আছে কারণ আপনি অ ডিকোপলড অবজেক্টগুলিকে সহজেই উপহাস করতে পারেন। ইন্টারফেসের ব্যবহারের সাহায্যে আপনি প্রতিটি বস্তুকে সহজেই উপহাস এবং পরীক্ষা করতে পারেন। ৩. আপনি প্রোগ্রামটির প্রতিটি অংশটি আলগাভাবে decoupled হওয়ার পরে এর অন্য অংশটি কোড করার প্রয়োজন ছাড়াই এক সাথে সংশোধন করতে পারেন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.