সোজা ডিআই কোডের বিপরীতে আমাকে আইওসি পাত্রে কেন দরকার? [বন্ধ]


598

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

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

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

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


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

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

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

4
কেভিন, আসলে আমরা আইওসি ব্যবহার করছি। আইওসি সম্পর্কে সবাইকে শেখানো এতটা কঠিন ছিল না।
ভাদিম

21
মডারেটররা কেন ব্যাপকহারে উত্সাহিত এবং দরকারী প্রশ্নগুলি বন্ধ করে দেয় তা আমার কোনও ধারণা নেই। সম্ভবত এই ক্ষেত্রে, উইল প্রশ্নটি বুঝতে পারে না, বা লোকেরা স্ট্যাকেক্সচেঞ্জের জন্য কী ব্যবহার করে তা সে বুঝতে পারে না? যদি এটি "স্ট্যাকেক্সচেঞ্জের প্রশ্নোত্তর ফর্ম্যাটটির জন্য উপযুক্ত নয়" তবে সম্ভবত বিবেচনা করুন যে আপনার নীতিটি ভুল এবং শত শত ভোট এবং আপ-ভোট কার্যকর উত্তর সহ এই শত শত দরকারী প্রশ্ন নয়।
নিক

উত্তর:


441

বাহ, বিশ্বাস করতে পারছেন না যে জোল এর পক্ষে হবে:

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

এটার উপরে:

var svc = IoC.Resolve<IShippingService>();

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

আইওসি পাত্রে জটিল হতে পারে, হ্যাঁ। তবে এই সাধারণ ক্ষেত্রে আমি এটি অবিশ্বাস্যভাবে সহজ দেখিয়েছি।


ঠিক আছে, এর আরও আরও ন্যায়সঙ্গত করা যাক। ধরা যাক আপনার কিছু সত্ত্বা বা মডেল অবজেক্ট রয়েছে যা আপনি একটি স্মার্ট UI তে আবদ্ধ করতে চান। এই স্মার্ট ইউআই (আমরা এটি শিন্ডোস মর্মস বলব) আপনি INotifyPropertyChanged প্রয়োগ করতে চান যাতে এটি ট্র্যাকিং পরিবর্তন করতে পারে এবং সেই অনুযায়ী ইউআই আপডেট করতে পারে।

"ঠিক আছে, এটি এত কঠিন শোনায় না" তাই আপনি লিখতে শুরু করুন।

আপনি এটি দিয়ে শুরু করুন:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime CustomerSince { get; set; }
    public string Status { get; set; }
}

..এবং দিয়ে শেষ এই :

public class UglyCustomer : INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            string oldValue = _firstName;
            _firstName = value;
            if(oldValue != value)
                OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            string oldValue = _lastName;
            _lastName = value;
            if(oldValue != value)
                OnPropertyChanged("LastName");
        }
    }

    private DateTime _customerSince;
    public DateTime CustomerSince
    {
        get { return _customerSince; }
        set
        {
            DateTime oldValue = _customerSince;
            _customerSince = value;
            if(oldValue != value)
                OnPropertyChanged("CustomerSince");
        }
    }

    private string _status;
    public string Status
    {
        get { return _status; }
        set
        {
            string oldValue = _status;
            _status = value;
            if(oldValue != value)
                OnPropertyChanged("Status");
        }
    }

    protected virtual void OnPropertyChanged(string property)
    {
        var propertyChanged = PropertyChanged;

        if(propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(property));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

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

এই শব্দটি কি কখনও শুনবেন, কাজটি আরও স্মার্ট, শক্ত নয়?

আচ্ছা কল্পনা করুন আপনার দলের কোনও স্মার্ট লোক এসে বলল: "এখানে একটি সহজ উপায়"

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

আপনি কোন আইওসি সরঞ্জামটি ব্যবহার করছেন তার উপর নির্ভর করে আপনি এমন কিছু করতে পারেন যা দেখায়:

var bindingFriendlyInstance = IoC.Resolve<Customer>(new NotifyPropertyChangedWrapper());

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

এই যাদু কি? হ্যাঁ ! আপনি যদি এই কোডটি তার কাজটি করে এমনটি বিশ্বাস করতে পারেন তবে আপনি সেই সম্পত্তি মোমবো-জাম্বো মোড়কে নিরাপদে এড়িয়ে যেতে পারেন। আপনার ব্যবসায়ের সমস্যার সমাধান করতে হবে।

এওপি করতে আইওসি সরঞ্জামের আরও কয়েকটি আকর্ষণীয় ব্যবহার:

  • ঘোষিত এবং নেস্টেড ডাটাবেস লেনদেন
  • কাজের ঘোষণাযুক্ত এবং নেস্টেড ইউনিট
  • লগিং
  • প্রাক / পোস্ট শর্তাদি (চুক্তি অনুসারে নকশা করা)

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

17
আপনি INotifyPropertyChanged মোড়ক ব্যবহার করে প্রচুর স্বচ্ছতার ত্যাগ করেন। সেই নদীর গভীরতানির্ণয়টি শুরু হতে যদি আপনার কয়েক মিনিটেরও বেশি সময় লাগে তবে আপনি ভুল ব্যবসায়। আপনার কোডটির ভারবোসিটি করার সময় কম কিছু হয় না!
বোঝা

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

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

30
এটি যাই হোক না কেন (আইওসি, ডায়নামিকপ্রক্সি, এওপি বা ব্ল্যাক ম্যাজিক ) কেউ আমাকে কাঠামোর একটি নিবন্ধ / নির্দিষ্ট ডকুমেন্টেশনের সাথে লিঙ্ক করতে পারেন যা এটি অর্জনের জন্য আরও বিশদ সরবরাহ করে?
fostandy

138

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

আমি ব্যক্তিগতভাবে কীভাবে আইওসি সম্প্রদায়টি মার্টিন ফোলারের একটি সুন্দর, মার্জিত নিবন্ধটি নিয়েছিলাম এবং এটিকে 200-300 পৃষ্ঠার ম্যানুয়াল সহ জটিল কাঠামোগত একগুচ্ছ রূপে রূপান্তরিত করেছি তা সম্পর্কে আমি ব্যক্তিগতভাবে হতবাক হয়েছি ।

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

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

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


81
আমি মনে করি আপনি আপনার সত্য কিছু জোয়েল মিশ্রিত করেছেন। আইওসি এবং পাত্রে প্রথম এসেছিল, তারপরে মার্টিনের গ্রন্থটি এসেছিল, তদ্বিপরীত নয়।
গ্লেন ব্লক

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

58
জোল আমি আপনার মতো একইভাবে ভাবতাম। তারপরে আমি সর্বাধিক বেসিক সেটআপটি কীভাবে চলতে হবে তা নির্ধারণের জন্য আমি আক্ষরিক এবং গুরুত্ব সহকারে পাঁচ মিনিট ব্যয় করেছি এবং 80/20 এর নিয়মটি কার্যকর হয়ে অবাক হয়েছি। এটি কোডগুলিকে বিশেষত সহজ ক্ষেত্রে খুব ক্লিনার করে তোলে।
জাস্টিন বোজনিয়র

55
আমি দু'বছরেরও কম সময় ধরে প্রোগ্রামিং করছি এবং আমি নিনজেক্ট উইকি পড়েছি এবং পেয়েছি। আমি তখন থেকে অনেক জায়গায় ডিআই ব্যবহার করে আসছি। তুমি কি তা দেখেছিলে? দুই বছরেরও কম সময় এবং একটি উইকিতে কয়েকটি পৃষ্ঠা পড়া। আমি উইজার্ড বা কিছুই না। আমি নিজেকে প্রতিভা হিসাবে বিবেচনা করি না, তবে আমার পক্ষে এটি বোঝা সহজ ছিল। আমি এমন কাউকে কল্পনা করতে পারি না যে সত্যিকারভাবে ওও বুঝতে পারে যে এটি বুঝতে সক্ষম নয়। এছাড়াও, আপনি কোন 200-300 পৃষ্ঠার ম্যানুয়ালগুলি উল্লেখ করছেন? আমি সেগুলি কখনই দেখিনি। আমি যে আইওসি পাত্রে ব্যবহার করেছি সেগুলির সমস্তগুলিই খুব সংক্ষিপ্ত এবং বিন্দুতে।
জেআর গার্সিয়া

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

37

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

যদি আপনার সিস্টেমটি এমন জটিলতায় পৌঁছে যায় যেখানে ম্যানুয়াল ডিআই একটি কোলাহলে পরিণত হয় (যা রক্ষণাবেক্ষণ বৃদ্ধি করে), একটি ডিআই কনটেইনার কাঠামোর টিম শেখার বক্ররেখার বিরুদ্ধে এটি বিবেচনা করুন।

নির্ভরতাকালীন আজীবন পরিচালনার উপর যদি আপনার আরও নিয়ন্ত্রণের প্রয়োজন হয় (এটি যদি আপনি সিঙ্গলটন প্যাটার্নটি প্রয়োগ করার প্রয়োজন বোধ করেন), ডিআই পাত্রে দেখুন।

আপনি যদি ডিআই কনটেইনার ব্যবহার করেন তবে কেবলমাত্র আপনার প্রয়োজনীয় বৈশিষ্ট্যগুলি ব্যবহার করুন। এক্সএমএল কনফিগারেশন ফাইলটি এড়িয়ে যান এবং পর্যাপ্ত হলে কোডে এটি কনফিগার করুন। কনস্ট্রাক্টর ইনজেকশন আটকে দিন। ইউনিটি বা স্ট্রাকচারম্যাপের মূল বিষয়গুলি কয়েকটি পৃষ্ঠায় ঘনীভূত হতে পারে।

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


খুব ভাল সাড়া। ম্যানুয়াল ইনজেকশন কখনও কখনও কম জটিল হিসাবে বিবেচনা করা যেতে পারে বা না এমন একটি বিষয় সম্পর্কে আমি মতামতটিতে পৃথক হয়েছি is
wekempf

+1 টি। এখানে সেরা উত্তরগুলির মধ্যে একটি। ব্লগ নিবন্ধ লিঙ্ক জন্য ধন্যবাদ।
স্টাকেক্স - 10

1
সুষম দৃষ্টিভঙ্গির জন্য +1। আইওসি পাত্রে সর্বদা ভাল হয় না এবং সেগুলি সবসময় খারাপ হয় না। আপনি যদি প্রয়োজন দেখতে না পান তবে এটি ব্যবহার করবেন না। আপনি যদি কোনও প্রয়োজন দেখেন তবে কেবল সরঞ্জামটি রয়েছে তা জেনে নিন।
ফিল

32

আমার মতে আইওসির এক নম্বর সুবিধাটি হ'ল আপনার নির্ভরতাগুলির কনফিগারেশনকে কেন্দ্রিয় করার ক্ষমতা।

আপনি যদি বর্তমানে নির্ভরতা ইনজেকশন ব্যবহার করে থাকেন তবে আপনার কোডটি দেখতে এইরকম হতে পারে

public class CustomerPresenter
{
  public CustomerPresenter() : this(new CustomerView(), new CustomerService())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

আপনি যদি কোনও স্ট্যাটিক আইওসি ক্লাস ব্যবহার করেন তবে আইএমএইচও আরও বিভ্রান্তিকর, কনফিগারেশন ফাইলগুলি ব্যবহার করেন, আপনার কাছে এরকম কিছু থাকতে পারে:

public class CustomerPresenter
{
  public CustomerPresenter() : this(IoC.Resolve<ICustomerView>(), IoC.Resolve<ICustomerService>())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

তারপরে, আপনার স্ট্যাটিক আইওসি ক্লাসটি দেখতে এমন হবে, আমি এখানে ইউনিটি ব্যবহার করছি।

public static IoC
{
   private static readonly IUnityContainer _container;
   static IoC()
   {
     InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerView, CustomerView>();
      _container.RegisterType<ICustomerService, CustomerService>();
      // all other RegisterTypes and RegisterInstances can go here in one file.
      // one place to change dependencies is good.
   }
}

11
বেন, আপনি যে বিষয়টির কথা বলছেন তা হ'ল সার্ভিস লোকেশন, নির্ভরতা ইনজেকশন নয় - একটি পার্থক্য রয়েছে। আমি সবসময় প্রথমের চেয়ে প্রথমটির চেয়ে বেশি পছন্দ করি। স্টিভেনহারম্যান.ট.ব্লগ
আর্কাইভ/

23
আপনার ডিফল্ট কনস্ট্রাক্টরে আইওসি.র সমাধান <টি> না করার পরিবর্তে আপনার জন্য আইওসি ধারকটির অবজেক্টটি তৈরির দক্ষতাটি উপার্জন করা উচিত। সেই খালি নির্মাণকারীর হাত থেকে মুক্তি পান এবং আইওসি কনটেইনারটি আপনার জন্য বস্তুটি তৈরি করতে দিন। var উপস্থাপক = IoC. পুনরায় সমাধান <কাস্টমারপ্রিসেন্টার> (); ভাল খবর! সমস্ত নির্ভরতা ইতিমধ্যে বিরক্ত।
বেন স্কিমারমান

12
এই ধরণের কনফিগারেশনের কেন্দ্রীকরণের ডাউন-সাইড হ'ল জ্ঞানের ডি-কনটেস্টুয়ালাইজেশন। জোয়েল এই সমস্যাটি উল্লেখ করে বলেছিলেন, "কোড হয়ে যায়, সত্যি বলতে, পড়া অনেক কঠিন"।
স্কট বেলওয়ার 15

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

7
স্টিভ, আমি .NET পাঠ্যটি জানি এবং বহু বছর ধরে সেই পদচারণা করে। অন্যান্য মোড এবং ফর্মগুলির সাথে আমারও ঘনিষ্ঠ পরিচিতি রয়েছে এবং আমি দৃce়ভাবে বুঝতে পারি যে এখানে সত্যিকারের বাণিজ্য রয়েছে। আমি জানি কীভাবে এবং কখন এই ট্রেড অফগুলি করা যায়, তবে আমার কর্মজীবনের জীবনের বৈচিত্র্য আমাকে কমপক্ষে স্পষ্টভাবে জোয়েলের দৃষ্টিভঙ্গি বুঝতে দেয় understand আমি বেশিরভাগ সময় .NET মনো-সংস্কৃতিবিদদের চেয়ে বেশি সময় ধরে ব্যবহার করে আসছি এমন সরঞ্জাম এবং কৌশলগুলিতে আমাকে বক্তৃতা দেওয়ার পরিবর্তে আমাকে এমন কিছু বলুন যা আমি জানি না। আমি আমার মস্তিষ্কের স্ট্যাকটি Alt.net স্ট্যাসিস এবং গোঁড়ামির চেয়ে বৈচিত্র্যময়, সমালোচনামূলক চিন্তার জন্য সংরক্ষণ করি।
স্কট বেলওয়ার 19

32

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

public void GetPresenter()
{
    var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}

class CustomerPresenter
{
    private readonly ICustomerService service;
    public CustomerPresenter(ICustomerService service)
    {
        this.service = service;
    }
}

class CustomerService
{
    private readonly IRespository<Customer> repository;
    public CustomerService(IRespository<Customer> repository)
    {
        this.repository = repository;
    }
}

class CustomerRepository : IRespository<Customer>
{
    private readonly DB db;
    public CustomerRepository(DB db)
    {
        this.db = db;
    }
}

class DB { }

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

উদাহরণ স্বরূপ:

public static IoC
{
   private IUnityContainer _container;
   static IoC()
   {
       InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerService, CustomerService>();
      _container.RegisterType<IRepository<Customer>, CustomerRepository>();
   }

   static T Resolve<T>()
   {
      return _container.Resolve<T>();
   }
}

public void GetPresenter()
{
   var presenter = IoC.Resolve<CustomerPresenter>();
   // presenter is loaded and all of its nested child dependencies 
   // are automatically injected
   // -
   // Also, note that only the Interfaces need to be registered
   // the concrete types like DB and CustomerPresenter will automatically 
   // resolve.
}

কিন্তু আইওসি ক্লাসকে পরিষেবা লোকেটার অ্যান্টি-প্যাটার্ন ব্যবহার করে ডাকা হয়। স্ট্যাটিক টি রেজলভ <টি> () কল করার পরিবর্তে কনস্ট্রাক্টর ডিআই ব্যবহার করে কনট্রাক্টর ডি কি পাস করা উচিত?
মাইকেল ফ্রেইজিম

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

28

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

... অথবা সম্ভবত আইওসি পাত্রে ডেভেলপাররা স্পষ্ট ডকুমেন্টেশন লিখতে অক্ষম।

... অথবা অন্যথায় উভয়ই এক ডিগ্রি বা অন্য কোনও ক্ষেত্রে সত্য।

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

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


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

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

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

1
@ কেনেভিট, ভাল কথা, এটির একটি সহজ অ্যাপ্লিকেশন রয়েছে এবং ভাল পরীক্ষার কভারেজ দেওয়ার জন্যও বিরক্ত না করলে আইওসি কাঠামোটি ব্যবহার করা অকাল মনে হবে।
বিল কারভিন

27

একটি ধারক ব্যবহার করা বেশিরভাগই আবশ্যকীয় / স্ক্রিপ্টেড স্টাইল থেকে আরম্ভের পদ্ধতি এবং কনফিগারেশনটিকে একটি ঘোষণামূলক হিসাবে পরিবর্তন করতে হয়। এর কয়েকটি আলাদা উপকারী প্রভাব থাকতে পারে:

  • হেয়ারবলের মূল-প্রোগ্রামের স্টার্টআপ রুটিন হ্রাস করা ।
  • মোটামুটি গভীর স্থাপনার-সময় পুনরায় কনফিগারেশন ক্ষমতা সক্ষম করা ling
  • নির্ভরতা-ইনজেকশনযোগ্য স্টাইলকে নতুন কাজের জন্য সর্বনিম্ন প্রতিরোধের পথ তৈরি করা।

অবশ্যই, অসুবিধা হতে পারে:

  • জটিল স্টার্টআপ / শাটডাউন / লাইফসাইकल পরিচালনা প্রয়োজন এমন কোডটি সহজেই কোনও ধারক হিসাবে মানিয়ে নেওয়া যায় না।
  • আপনাকে সম্ভবত কোনও ব্যক্তিগত, প্রক্রিয়া এবং টিম সংস্কৃতি সংক্রান্ত সমস্যা নেভিগেট করতে হবে - তবে তারপরেই, আপনি কেন জিজ্ঞাসা করেছেন ...
  • বেশ কয়েকটি টুলকিটগুলি নিজেই হেভিওয়েট হয়ে উঠছে, অনেকগুলি ডিআই কনটেইনার বিরুদ্ধে প্রতিক্রিয়া হিসাবে শুরু হওয়া গভীর নির্ভরতাটিকে উত্সাহিত করছে।

23

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

সুতরাং, আপনার কাছে কোডের একটি গুচ্ছ রয়েছে যা ইতিমধ্যে কাজ করে। এবং আপনি অন্য কারও প্রয়োগের সাথে কেন এটি প্রতিস্থাপন করতে চান তা ভাবছেন।

তৃতীয় পক্ষের আইওসি ধারক বিবেচনা করার জন্য পেশাদার s

  • আপনি বিনামূল্যে বাগ স্থির করে নিন
  • আপনার চেয়ে গ্রন্থাগারের নকশা ভাল হতে পারে
  • লোকেরা নির্দিষ্ট গ্রন্থাগারের সাথে ইতিমধ্যে পরিচিত হতে পারে
  • আপনার চেয়ে গ্রন্থাগারটি দ্রুত হতে পারে
  • এতে কিছু বৈশিষ্ট্য থাকতে পারে যা আপনি বাস্তবায়িত করতে চান তবে কখনই সময় আসেনি (আপনার কাছে কোনও সার্ভিস লোকেটার রয়েছে?)

কনস

  • আপনি বিনামূল্যে বাগ প্রবর্তন করুন :)
  • গ্রন্থাগারের নকশা আপনার চেয়ে খারাপ হতে পারে
  • আপনাকে একটি নতুন এপিআই শিখতে হবে
  • অনেকগুলি বৈশিষ্ট্য যা আপনি কখনই ব্যবহার করবেন না
  • আপনি যে কোডটি লেখেন নি সেগুলি ডিবাগ করা সাধারণত কঠিন
  • পূর্ববর্তী আইওসি ধারক থেকে স্থানান্তরিত করা ক্লান্তিকর হতে পারে

সুতরাং, আপনার পক্ষে আপনার পক্ষে ভাল বিবেচনা করুন এবং একটি সিদ্ধান্ত নিন।


আমি আপনার সাথে একমত হয়েছি স্যাম - ডিআই হ'ল এক ধরণের আইওসি, সুতরাং যদি মূল পোস্টারটি ডিআই করছে, তারা ইতিমধ্যে আইওসি করছে তাই তাদের আসল প্রশ্নটি কেন আপনার নিজের রোল।
জেমি লভ

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

17

আমি মনে করি আইওসি ব্যবহার করে আইওসির বেশিরভাগ মান সংগ্রহ করা হয়। যেহেতু আপনি ইতিমধ্যে এটি করছেন, বাকি সুবিধাগুলি ইনক্রিমেন্টাল।

আপনি যে মানটি পেয়েছেন তা নির্ভর করবে আপনি যে ধরণের অ্যাপ্লিকেশনটিতে কাজ করছেন তার উপর:

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

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

  • আপনি যদি কিছু ক্রস কাটিয়া উদ্বেগের জন্য এওপি ব্যবহার করতে চান তবে আইওসি পদ্ধতি আহ্বানকে বাধা দেওয়ার জন্য হুক সরবরাহ করে। প্রকল্পগুলিতে এটি কম সাধারণভাবে করা হয় তবে আইওসি এটি সহজ করে তোলে।

আমি এর আগে কার্যকারিতা লিখেছি তবে এখন যদি এই বৈশিষ্টগুলির কোনও দরকার হয় তবে আমি এটি প্রাক-বিল্ট এবং পরীক্ষিত সরঞ্জামটি ব্যবহার করব যদি এটি আমার স্থাপত্যের সাথে খাপ খায় fits

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

আমি একটি আইওসি পাত্রে ব্যবহার করি এবং কার্যকারিতাটির প্রশংসা করি তবে স্বীকার করতে হবে যে আমি ট্রেড-অফটি লক্ষ্য করেছি: আমার কোডটি ক্লাস স্তরে আরও স্পষ্ট হয়ে উঠেছে এবং অ্যাপ্লিকেশন স্তরে কম স্পষ্ট হয়ে উঠেছে (অর্থাত্ নিয়ন্ত্রণ প্রবাহকে দৃশ্যমান করা)।


16

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

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

স্থির যাদুবিহীন ডিআই কেন এভাবে করবেন না:

interface IServiceA { }
interface IServiceB { }
class ServiceA : IServiceA { }
class ServiceB : IServiceB { }

class StubServiceA : IServiceA { }
class StubServiceB : IServiceB { }

interface IRoot { IMiddle Middle { get; set; } }
interface IMiddle { ILeaf Leaf { get; set; } }
interface ILeaf { }

class Root : IRoot
{
    public IMiddle Middle { get; set; }

    public Root(IMiddle middle)
    {
        Middle = middle;
    }

}

class Middle : IMiddle
{
    public ILeaf Leaf { get; set; }

    public Middle(ILeaf leaf)
    {
        Leaf = leaf;
    }
}

class Leaf : ILeaf
{
    IServiceA ServiceA { get; set; }
    IServiceB ServiceB { get; set; }

    public Leaf(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }
}


interface IApplicationFactory
{
    IRoot CreateRoot();
}

abstract class ApplicationAbstractFactory : IApplicationFactory
{
    protected abstract IServiceA ServiceA { get; }
    protected abstract IServiceB ServiceB { get; }

    protected IMiddle CreateMiddle()
    {
        return new Middle(CreateLeaf());
    }

    protected ILeaf CreateLeaf()
    {
        return new Leaf(ServiceA,ServiceB);
    }


    public IRoot CreateRoot()
    {
        return new Root(CreateMiddle());
    }
}

class ProductionApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new ServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new ServiceB(); }
    }
}

class FunctionalTestsApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new StubServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new StubServiceB(); }
    }
}


namespace ConsoleApplication5
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ProductionApplication();
            var root = factory.CreateRoot();

        }
    }

    //[TestFixture]
    class FunctionalTests
    {
        //[Test]
        public void Test()
        {
            var factory = new FunctionalTestsApplication();
            var root = factory.CreateRoot();
        }
    }
}

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

সুবিধাদি:

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

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


এটি আইওসির বিরুদ্ধে আর্গুমেন্টের মতো বলে মনে হচ্ছে না, তবে কনফিগারযোগ্য আইওসি ফ্রেমওয়ার্কগুলির বিরুদ্ধে একটি যুক্তি । এখানে কি আপনার ফ্যাক্টরিগুলি কেবল সহজ হার্ড-কোডড আইওসিগুলিতে সিদ্ধ হয় না ?
মিঃ মাইন্ডার ২১ শে

আমি মনে করি পোস্টারটি যখন আইওসি-র উল্লেখ করেছিল তখন একটি আইওসি ধারক কাঠামো বোঝানো হয়েছিল। মূল লেখার জন্য ধন্যবাদ এটি আমাকে বিন্যাস ছাড়াই যেতে রাজি করতে সহায়তা করে। সুতরাং যদি এটি পরীক্ষাগুলিতে এবং উত্পাদন কোডে কনফিগারযোগ্য হয় তবে একটি "কনফিগারযোগ্য" কাঠামোর সুবিধা কী?
হুগি

পরিভাষা সম্পর্কে আমার বোঝা থেকে, বিপরীতকরণের নিয়ন্ত্রণ মানে রান-টাইমে নির্ভরতা সন্ধান করা। হ্যাঁ, আপনি বলতে পারেন কারখানাটি মূলত একটি হার্ড-কোডড বা স্ট্যাটিক ধারক, তবে এটি কোনও আইওসি ধারক নয়। প্রকারগুলি সংকলনের সময়ে সমাধান করা হয়। এটি কনফিগারযোগ্য ফ্রেমওয়ার্কগুলি ব্যবহারের বিরুদ্ধে একটি যুক্তি যা রানটাইম সময়ে ধরণের সমাধান করতে অভিধানের লকআপগুলি ব্যবহার করে।
ম্যাক্সিম 7007

14

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

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

আইওসি কন্টেইনার ব্যবহার না করে আমাকে সেটিংস এবং / অথবা মেটাডেটা 2, 3, ..., এন অবজেক্টের মধ্য দিয়ে পাস করতে হবে এটির প্রয়োজনীয় বস্তুটি আসলে এটি ব্যবহার করার আগে।

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


2
এটি একটি বিশাল প্লাস। বিশ্বাস করা যায় না, এর আগে আর কেউ উল্লেখ করেনি। অস্থায়ী বস্তুগুলি পাস করার বা সঞ্চয় করার প্রয়োজন ছাড়াই কোডকে অনেক বেশি পরিষ্কার করে তোলে।
ফিঙ্গলাস

1
@ কিবল গ্লোবাল অবজেক্টস দুর্দান্ত কাজ করে ... আপনি যদি চান যে আপনার কোড বেসটি একটি দৃ coup়ভাবে মিলিত, অ-পরীক্ষামূলক দুঃস্বপ্ন হতে পারে যা সময়ের সাথে সাথে সংশোধন করা আরও কঠিন এবং শক্ত হয়। শুভকামনা যে।
জেফ্রি ক্যামেরন

2
@JeffreyCameron আইওসি কনটেইনার হয় বিশ্বব্যাপী বস্তু। এটি আপনার বিশ্ব নির্ভরতা অপসারণ করে না।
কিবল

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

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

14

আপনি চাইলে আইওসি ফ্রেমওয়ার্কগুলি দুর্দান্ত ...

  • ... প্রকারের সুরক্ষা ফেলে দিন। অনেকগুলি (সমস্ত?) আইওসি ফ্রেমওয়ার্কগুলি আপনাকে কিছু নির্দিষ্টভাবে সঠিকভাবে আপ করা উচিত হতে চাইলে কোডটি কার্যকর করতে বাধ্য করে। "আরে! আশা করি আমি সবকিছু সেট আপ করেছি তাই আমার এই 100 টি ক্লাসের আরম্ভিকরণগুলি উত্পাদনে ব্যর্থ হবে না, নাল-পয়েন্টার ব্যতিক্রম ছুঁড়ে ফেলবে!"

  • ... globals সঙ্গে আপনার কোড শিবিকা (আইওসি অবকাঠামো হয় সব বিশ্বব্যাপী রাজ্যের পরিবর্তন সম্পর্কে)।

  • ... অস্পষ্ট নির্ভরশীলতার সাথে ক্রেপি কোড লিখুন যা রিফ্যাক্টর করা শক্ত কারণ আপনি কখনই জানেন না কিসের উপর নির্ভর করে।

আইওসির সমস্যা হ'ল যে লোকেরা তাদের ব্যবহার করে তারা কোড লিখতে ব্যবহার করত

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

যা স্পষ্টতই ত্রুটিযুক্ত যেহেতু ফু এবং বারের মধ্যে নির্ভরতা হার্ড-ওয়্যার্ড। তারপরে তারা বুঝতে পারল কোডের মতো লেখাই ভাল

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

যা ত্রুটিযুক্ত, কিন্তু কম স্পষ্টতই তাই। হাস্কেলের মধ্যে প্রকারটি Foo()হবে IO Fooতবে আপনি প্রকৃতপক্ষে IOপার্টটি চান না এবং এটি একটি সতর্কতা চিহ্ন হতে হবে যা আপনি যদি পেয়ে থাকেন তবে আপনার ডিজাইনে কিছু ভুল হয়েছে।

এটি থেকে মুক্তি পেতে (আইও-অংশ), আইওসি-ফ্রেমওয়ার্কের সমস্ত সুবিধা পান এবং এর কোনও অসুবিধা আপনি পরিবর্তে একটি বিমূর্ত কারখানাটি ব্যবহার করতে পারেন।

সঠিক সমাধান কিছু হবে

data Foo = Foo { apa :: Bar }

অথবা হতে পারে

data Foo = forall b. (IBar b) => Foo { apa :: b }

এবং ইনজেকশন (তবে আমি এটি ইনজেকশন বলব না) বার।

এছাড়াও: এরিক মেইজার (লিনকিউ আবিষ্কারক) এর সাথে এই ভিডিওটি দেখুন যেখানে তিনি বলেছেন যে ডিআই এমন লোকদের জন্য যারা গণিত জানেন না (এবং আমি আরও সম্মত হতে পারিনি): http://www.youtube.com/watch?v = 8Mttjyf-8P4

মিঃ স্পলস্কির বিপরীতে আমি বিশ্বাস করি না যে লোকেরা আইওসি-ফ্রেমওয়ার্ক ব্যবহার করে তারা খুব স্মার্ট - আমি কেবল বিশ্বাস করি যে তারা গণিত জানেন না।


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

আপনি প্রকারের সুরক্ষা দূরে ফেলেছেন যেহেতু আপনি জানেন না যে প্রকারটি ওয়্যার্ড হয়েছে কি না আইওসি-ধারক (আইওসি <আইবার> টাইপটি IBarআসলে তা নয় IO IBar) .. এবং হ্যাঁ, হাস্কেল-উদাহরণে আমি নাল-রেফারেন্স পেতে পারি না।
ফিনসন

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

2
আমি আপনার 1 ম বিষয়টির সাথে কিছুটা হলেও একমত, আমি ২ য় এর কিছু ব্যাখ্যা চাই এবং তৃতীয়টি আমার পক্ষে কখনও সমস্যা হয়নি। আপনার সি # নমুনাটি আইওসি ধারকটিকে পরিষেবা লোকেটার হিসাবে ব্যবহার করে, একটি সাধারণ ভুল। এবং সি # বনাম হাস্কেল = আপেল বনাম কমলার তুলনা করছেন।
মৌরিসিও শেফার

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

10

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

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

var merger = new SimpleWorkflowInstanceMerger(
    new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
    new WorkflowAnswerRowUtil(
        new WorkflowFieldAnswerEntMapper(),
        new ActivityFormFieldDisplayInfoEntMapper(),
        new FieldEntMapper()),
    new AnswerRowMergeInfoRepository());

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

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

অন্য কথায়, আপনি যদি আইওসি পাত্রে পছন্দ না করেন তবে আপনি সম্ভবত নির্ভরতা ইনজেকশনটি করছেন না বলে মনে করছেন।

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

public class MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController()
    {
        _simpleMerger = new SimpleWorkflowInstanceMerger(
            new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
            new WorkflowAnswerRowUtil(
                new WorkflowFieldAnswerEntMapper(),
                new ActivityFormFieldDisplayInfoEntMapper(),
                new FieldEntMapper()),
            new AnswerRowMergeInfoRepository())
    }
    ...
}

এখন এটি একটি ডিআই ফ্রেমওয়ার্ক আপনার জন্য এটি করার অনুমতি দিয়ে এটি তুলনা করুন:

public MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController(ISimpleWorkflowInstanceMerger simpleMerger)
    {
        _simpleMerger = simpleMerger;
    }
    ...
}

ডিআই ফ্রেমওয়ার্ক ব্যবহার করে নোট করুন:

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

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


9

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

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

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


8

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


7

আপনার কোনও আইওসি ধারক দরকার নেই

তবে আপনি যদি ডিআই প্যাটার্নটি কঠোরভাবে অনুসরণ করেন তবে আপনি দেখতে পাবেন যে এটির সাথে এক টন রিরানডেন্ট, বোরিং কোডটি মুছে ফেলা হবে।

যাইহোক, কোনও লাইব্রেরি / কাঠামো ব্যবহার করার জন্য এটি সবচেয়ে ভাল সময় - যখন আপনি বুঝতে পারবেন এটি কী করছে এবং লাইব্রেরি ছাড়া এটি করতে পারে।


6

আমি ঠিক তাই ঘটতে পেরেছি যে বাড়ির বর্ধিত ডিআই কোডটি বের করে আনা এবং এটি একটি আইওসি দিয়ে প্রতিস্থাপন করা। আমি সম্ভবত ২০০ টিরও বেশি কোডের কোডটি মুছে ফেলেছি এবং এটি প্রায় 10 দিয়ে প্রতিস্থাপন করেছি Yes হ্যাঁ, ধারকটি (উইনসর) কীভাবে ব্যবহার করতে হয় সে সম্পর্কে আমাকে কিছুটা শিখতে হয়েছিল, তবে আমি ইন্টারনেট ইঞ্জিনিয়ারিংয়ে ইন্টারনেট প্রযুক্তিতে কাজ করছি একবিংশ শতাব্দী তাই আমি যে অভ্যস্ত। আমি সম্ভবত প্রায় 20 মিনিট কীভাবে টস দেখেছি spent এটা আমার সময় ভাল ছিল।


3
"তবে আমি একবিংশ শতাব্দীতে ইন্টারনেট প্রযুক্তি নিয়ে কাজ করা একজন প্রকৌশলী তাই আমি তার সাথে
অভ্যস্ত

5

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

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

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


1
আমরা কেন তাদের তুলতে কাজ করার চেয়ে সর্বনিম্ন সাধারণ ডিনোমিনেটরকে সন্তুষ্ট করতে থাকি?
স্টিভেনহারম্যান

4
আমি সন্তুষ্টির বিষয়ে কিছু বলিনি। আমি কেবল বলেছি যে উন্নত পরিস্থিতিগুলি নতুন ডেভসের জন্য জিনিসগুলিকে আরও নিবিড় করে তুলতে পারে - এটি একটি সত্য। আমি বলিনি "তাই করবেন না"। তবে তারপরেও (শয়তানের পক্ষের পক্ষে সময়) একই জিনিস সম্পাদন করার জন্য অন্যান্য উপায় রয়েছে যা একটি কোডবেসকে আরও স্পষ্ট এবং কাছে পৌঁছাতে সক্ষম করে। আপনার অবকাঠামো সরঞ্জামের কাস্টম কনফিগারেশনে জটিলতা লুকিয়ে রাখা ঠিক কারণ আপনি সঠিক কারণটি করতে পারেন না এবং এটি কাউকে টানতে পারে না।
অ্যারন লার্চ

4

Ittক্য সম্পর্কে Ditos। খুব বড় হয়ে উঠুন এবং আপনি রাফটারগুলিতে ক্রিকিং শুনতে পাচ্ছেন।

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


2

.NET বিশ্বে এওপি খুব বেশি জনপ্রিয় নয়, সুতরাং ডিআই-র জন্য একটি ফ্রেমওয়ার্ক আপনার একমাত্র আসল বিকল্প, আপনি নিজেরাই লেখেন বা অন্য কাঠামো ব্যবহার করুন whether

আপনি যদি এওপি ব্যবহার করেন তবে আপনি নিজের অ্যাপ্লিকেশনটি সংকলন করার সময় ইনজেকশন করতে পারবেন যা জাভাতে বেশি সাধারণ।

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


নতুন এমইএফ ফ্রেমওয়ার্কটি নেট .NET এর জন্য কেবল এটির অনুমতি দেয় এবং আমার অবশ্যই বলতে হবে কোডটি আরও পরিষ্কার এবং বুঝতে সহজ, এটি ডিআই ধারণাটি বুঝতে অনেক সহজ করে তোলে।
Terjetyl

4
@TT: MEF হয় না নির্ভরশীলতার ইনজেকশন ধারক এবং Aop সঙ্গে কিছুই করার আছে।
মৌরিসিও শেফার

2

তো, প্রায় 3 বছর কেটে গেছে, তাই না?

  1. যারা আইওসি ফ্রেমওয়ার্কের পক্ষে মন্তব্য করেছেন তাদের 50% তারা আইওসি এবং আইওসি ফ্রেমওয়ার্কগুলির মধ্যে পার্থক্য বুঝতে পারে না। আমি সন্দেহ করি তারা জানে যে আপনি কোনও অ্যাপ সার্ভারে স্থাপন না করে কোড লিখতে পারেন

  2. যদি আমরা সর্বাধিক জনপ্রিয় জাভা স্প্রিং ফ্রেমওয়ার্কটি গ্রহণ করি তবে এটি আইওসি কনফিগারেশনটি এক্সএমএল থেকে কোডে সরানো হয়েছে এবং এখন এটি দেখতে দেখতে

`@ কনফিগারেশন পাবলিক ক্লাস অ্যাপকনফিগ {

public @Bean TransferService transferService() {
    return new TransferServiceImpl(accountRepository());
}

public @Bean AccountRepository accountRepository() {
    return new InMemoryAccountRepository();
}

`` এবং এটি সঠিকভাবে করার জন্য আমাদের একটি কাঠামো দরকার?


1

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

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

যদি হ্যাঁ, তবে আপনার আইওসি পাত্রে প্রয়োজন হতে পারে। যদি তা না হয় তবে আপনি কেবল সূচনাটি সরিয়ে নিয়ে যাচ্ছেন যেখান থেকে বিকাশকারী সহজেই এটি দেখতে পারেন।

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

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

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

কারো কি কোন চিন্তা আছে এ ব্যাপারে?


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

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

এক্সএমএল কনফিগারেশন / আইওসি করতে আপনার কোনও ইন্টারফেসের দরকার নেই। আমি কেবলমাত্র 8 ডলার পৃষ্ঠা এবং 5 বা 6 পরিষেবা সহ একটি ছোট প্রকল্পে স্বচ্ছতার ক্ষেত্রে দুর্দান্ত উন্নতি পেয়েছি। পরিষেবাগুলি এবং নিয়ন্ত্রকদের আর আঠালো কোডের প্রয়োজন নেই বলে কম অবকাশ আছে's
টমাস ডাব্লু

1

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


1

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

কেবল স্পষ্ট করে বলার জন্য, সুবিধাগুলি যেমন আমি তাদের দেখছি: 1) কোডের মূলের এক জায়গায় সমস্ত নতুন বিবৃতি। 2) এক পরিবর্তন সহ সম্পূর্ণরূপে পুনরায় ফ্যাক্টর কোড। 3) 'শীতল গুণক' এর জন্য অতিরিক্ত পয়েন্টগুলি এর কারণ ... ভাল: শীতল। : P


1

আমি কেন আমার দৃষ্টিকোণ থেকে আইওসি ভাল না হতে পারে তা জানার চেষ্টা করব।

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

  1. আপনার যখন অনেকগুলি নির্ভরতার সাথে পরিস্থিতি হয় আপনি সংগঠিত করতে চান
  2. যখন আপনি তৃতীয় পক্ষের পণ্যটির সাথে আপনার কোডটি সংযুক্ত করার বিষয়ে চিন্তা করবেন না
  3. আপনার বিকাশকারীরা যখন কোনও নতুন সরঞ্জামের সাথে কীভাবে কাজ করবেন তা শিখতে চান

1: এটি প্রায়শই নয় যে আপনার কোডে আপনার এতগুলি নির্ভরতা থাকে বা আপনি নকশায় তাড়াতাড়ি সচেতন হন। বিমূর্ত চিন্তাভাবনা কার্যকর যখন বিমূর্ত চিন্তাভাবনা কার্যকর হয় is

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

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

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

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

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


0

ব্যক্তিগতভাবে, আমি আমার অ্যাপ্লিকেশনটির কাঠামোর মানচিত্রের কোনও ধরণের হিসাবে আইওসি ব্যবহার করি (হ্যাঁ, আমি স্ট্রাকচারম্যাপকেও পছন্দ করি;))। পরীক্ষাগুলির সময় Moq বাস্তবায়নগুলির সাথে আমার usuual ইন্টারফেস বাস্তবায়নগুলি সহজেই প্রতিস্থাপন করে। আমার আইওসি-ফ্রেমওয়ার্কে একটি নতুন ইন-কল করার মতো একটি পরীক্ষার সেটআপ তৈরি করা সহজ হতে পারে, যে কোনও ক্লাসকে মক দিয়ে আমার পরীক্ষার সীমা নির্ধারণ করা যায়।

এটি সম্ভবত আইওসি-র জন্য নেই, তবে এটিই আমি নিজেকে সবচেয়ে বেশি ব্যবহার করে দেখতে পাই ..




0

আমি বুঝতে পারি এটি একটি পুরানো পোস্ট, তবে এটি এখনও যুক্তিযুক্তভাবে সক্রিয় বলে মনে হয়েছে এবং আমি ভেবেছিলাম যে আমি কয়েকটি পয়েন্ট অবদান রাখতে চাই যা অন্যান্য উত্তরে এখনও উল্লেখ করা হয়নি।

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

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

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


-8

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


1
আপনি কি একটি উদাহরণ দিতে পারেন? অন্য যে কোনও অ্যাপ্লিকেশন ধরণের তুলনায় এএসপি.নেটে ডিআই কীভাবে আলাদা?
tofi9
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.