নির্ভরতা ইনজেকশন পাত্রে সুবিধা কী কী?


104

নির্ভরতা ইঞ্জেকশন নিজেই উপকারিতা আমি বুঝতে পারি। উদাহরণস্বরূপ বসন্ত নেওয়া যাক। আমি অন্যান্য স্প্রিং বৈশিষ্ট্যগুলির মতো এওপি, বিভিন্ন ধরণের সহায়তাকারী ইত্যাদির সুবিধাও বুঝতে পারি I'm আমি কেবল ভাবছি, এক্সএমএল কনফিগারেশনের সুবিধাগুলি কী কী:

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

সাধারণ পুরানো জাভা কোডের সাথে তুলনা করুন যেমন:

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

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


আপডেট:
ক্ষেত্রে

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

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

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


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


আপডেট 3:

ইন্টারফেস এবং তাদের কংক্রিট বাস্তবায়নের মধ্যে ম্যাপিংয়ের বাহ্যিক কনফিগারেশন

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

আপনি কোডিংয়ের সময় বাঁচান কারণ আপনি ম্যাপিংগুলি ঘোষণামূলকভাবে সরবরাহ করেন, কোনও পদ্ধতিগত কোডে নয়

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

নিয়ন্ত্রণের নীতিটির বিপরীতকরণ সহজ ইউনিট পরীক্ষার অনুমতি দেয় কারণ আপনি আসল বাস্তবায়নগুলি নকলগুলির সাথে প্রতিস্থাপন করতে পারেন (যেমন এসকিউএল ডাটাবেসটিকে মেমোরির সাথে প্রতিস্থাপনের মতো)

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

mary = new FakeFemale();

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

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


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


21
শেষ পর্যন্ত কেউ এই প্রশ্ন জিজ্ঞাসা করার সাহস ছিল। যখন বাস্তবায়ন আপনি (বা কমপক্ষে অবনতি) সরঞ্জাম / আইডিই সমর্থন বলি হিসাবে পরিবর্তন বাস্তবায়ন করতে চান কেন আপনি পুনরায় সংশোধন এড়াতে চান?
খ্রিস্টান ক্লাউজার

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

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

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

আমি নমুনা নিয়ে সমস্যা দেখছি। নীতিগুলি হ'ল ডেটা নয় ইনজেকশন পরিষেবাগুলি
জ্যাসেক সিজে

উত্তর:


40

আমার জন্য আইওসি ব্যবহারের অন্যতম প্রধান কারণ (এবং বাহ্যিক কনফিগারেশন ব্যবহার করা) এর দুটি ক্ষেত্রের চারপাশে:

  • পরীক্ষামূলক
  • উত্পাদন রক্ষণাবেক্ষণ

পরীক্ষামূলক

যদি আপনি নিজের পরীক্ষাকে 3 টি পরিস্থিতিতে বিভক্ত করেন (যা বৃহত্তর বিকাশে মোটামুটি স্বাভাবিক):

  1. অংশ পরিক্ষাকরণ
  2. ইন্টিগ্রেশন টেস্টিং
  3. ব্ল্যাক বক্স টেস্টিং

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

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

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

উত্পাদনের

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

সারসংক্ষেপ

আইওসি-র বহিরাগত কনফিগারেশনটি অন্যদের (অ-বিকাশকারী) আপনার অ্যাপ্লিকেশনটি কনফিগার করার ক্ষমতা প্রদান থেকে আসে এমন প্রধান সুবিধাগুলি আমার অভিজ্ঞতা হিসাবে এটি কেবলমাত্র পরিস্থিতিতে সীমিত সংখ্যায় কার্যকর:

  • অ্যাপ্লিকেশনটি একাধিক সাইট / ক্লায়েন্টগুলিতে বিতরণ করা হয়েছে যেখানে পরিবেশগুলি পৃথক হবে।
  • উত্পাদনের পরিবেশ এবং সেটআপের উপর সীমিত বিকাশ নিয়ন্ত্রণ / ইনপুট।
  • পরীক্ষার পরিস্থিতি।

অনুশীলনে আমি দেখতে পেয়েছি যে পরিবেশের উপর আপনার নিয়ন্ত্রণ রয়েছে এমন কিছু বিকাশ করার পরেও এটি চালিত হবে, সময়ের সাথে সাথে অন্য কাউকে কনফিগারেশন পরিবর্তন করার ক্ষমতা দেওয়া আরও ভাল:

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

দ্রষ্টব্য: অ্যাপ্লিকেশনটি সম্পূর্ণ সমাধানটিকে বোঝায় (কেবলমাত্র কার্যকরযোগ্য নয়), সুতরাং অ্যাপ্লিকেশনটি চালানোর জন্য প্রয়োজনীয় সমস্ত ফাইল


14

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

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

ডিআই নিদর্শন ব্যবহার করে নির্মিত একটি সিস্টেমের শক্তি:

  1. ডিআই কোড পুনরায় ব্যবহার করা সহজ কারণ 'নির্ভরশীল' কার্যকারিতাটি সুস্পষ্ট সংজ্ঞায়িত ইন্টারফেসগুলিতে এক্সট্রাপোলেটেড করা হয়, যার জন্য পৃথক বস্তু যার কনফিগারেশনটি উপযুক্ত অ্যাপ্লিকেশন প্ল্যাটফর্ম দ্বারা পরিচালিত হয় ইচ্ছামত অন্য বস্তুগুলিতে প্লাগ করতে পারে।
  2. ডিআই কোড পরীক্ষা করা আরও সহজ। আপনার অ্যাপ্লিকেশন লজিক দ্বারা প্রত্যাশিত ইন্টারফেস প্রয়োগ করে 'মক' অবজেক্ট তৈরি করে কোনও বস্তু দ্বারা প্রকাশিত কার্যকারিতা একটি কালো বাক্সে পরীক্ষা করা যেতে পারে।
  3. ডিআই কোডটি আরও নমনীয়। এটি সহজাতভাবে আলগাভাবে সংযুক্ত কোড - একটি চূড়ান্ত। এটি প্রোগ্রামারটিকে এক প্রান্তে তাদের প্রয়োজনীয় ইন্টারফেস এবং অন্যদিকে তাদের প্রকাশিত ইন্টারফেসের ভিত্তিতে কীভাবে অবজেক্টগুলি সংযুক্ত থাকে তা বাছতে এবং চয়ন করতে সহায়তা করে।
  4. ডিআই অবজেক্টগুলির বাহ্যিক (এক্সএমএল) কনফিগারেশনের অর্থ অন্যরা অপ্রত্যাশিত দিকগুলিতে আপনার কোডটি কাস্টমাইজ করতে পারে।
  5. বাহ্যিক কনফিগারেশন হ'ল উদ্বেগের প্যাটার্নের একটি পৃথককরণ যা অবজেক্ট ইনিশিয়ালাইজেশন এবং অবজেক্ট আন্তঃনির্ভরতা ব্যবস্থাপনার সমস্ত সমস্যা অ্যাপ্লিকেশন সার্ভার দ্বারা পরিচালিত হতে পারে।
  6. নোট করুন বাহ্যিক কনফিগারেশন ডিআই প্যাটার্ন ব্যবহার করার প্রয়োজন হয় না, সাধারণ আন্তঃসংযোগের জন্য একটি ছোট বিল্ডার অবজেক্ট প্রায়শই পর্যাপ্ত। দুজনের মধ্যে নমনীয়তায় বাণিজ্য রয়েছে। একটি বিল্ডার অবজেক্ট বাহ্যিকভাবে দৃশ্যমান কনফিগারেশন ফাইলের মতো বিকল্প হিসাবে নমনীয় নয়। ডিআই সিস্টেমের বিকাশকারীকে সুবিধার্থে নমনীয়তার সুবিধাগুলি বিবেচনা করতে হবে, কনফিগারেশনের ফাইল হিসাবে প্রকাশিত হিসাবে ছোট স্কেল, অবজেক্ট নির্মানের উপর সূক্ষ্ম শস্য নিয়ন্ত্রণ নিয়ন্ত্রণের বিভ্রান্তি এবং রক্ষণাবেক্ষণের ব্যয়কে বাড়িয়ে তুলতে হবে।

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

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

আপনি ঠিক বলেছেন যে কোডের একমাত্র 10s লাইন ব্যবহারের বিষয়টি বেশ কয়েকটি অবজেক্ট প্লাস XML কনফিগারেশন ফাইলের একটি সিরিজের চেয়ে বোঝা সহজ। তবে সর্বাধিক শক্তিশালী ডিজাইনের ধরণগুলির মতো, সিস্টেমে আপনি নতুন বৈশিষ্ট্য যুক্ত করতে থাকায় লাভগুলি পাওয়া যায়।

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


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

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

7

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

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

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

যাইহোক, এক্সএমএল কনফিগারেশনটি আমার একটি পোষা প্রাইভের কিছুটা ... আমি এটিকে যেকোন মূল্যে এড়াতে চেষ্টা করি।


5

যে কোনও সময় আপনি আপনার কোডটি ডেটাতে পরিবর্তন করতে পারবেন যখন আপনি সঠিক দিকে পদক্ষেপ নিচ্ছেন।

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

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

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


উপলব্ধি করে, এই দৃষ্টিকোণে এটি সম্পর্কে
ভাবেননি

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

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

1
"যে কোনও সময় আপনি আপনার কোডটি ডেটাতে পরিবর্তন করতে পারবেন যখন আপনি সঠিক দিকে পদক্ষেপ নিচ্ছেন" " সফট কোডিং বিরোধী-প্যাটার্নে আপনাকে স্বাগতম।
রায়েডওয়াল্ড

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

3

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

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

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

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

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

<bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

পরিবর্তে, এটি আরও দেখতে লাগছিল:

public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}

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


3

আমি আপনার উত্তর আছে

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

বিল্ড সিস্টেম এবং বাহ্যিক কনফিগারেশন সম্পর্কিত অন্যান্য দরকারী ব্যবহারের কেস:

  • বিভিন্ন বিল্ডের জন্য একক কোড বেসের জন্য ইনজেকশন শৈলী / স্টাইলশিট
  • আপনার একক কোড বেসের জন্য গতিশীল সামগ্রীর বিভিন্ন সেট (বা তাদের উল্লেখ) ইনজেক্ট করা
  • বিভিন্ন বিল্ড / ক্লায়েন্টের জন্য স্থানীয়করণ প্রসঙ্গে ইনজেকশন
  • একটি ওয়েব সার্ভিস ইউআরআই একটি ব্যাকআপ সার্ভারে পরিবর্তন করা (যখন প্রধানটি নীচে যাবে)

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

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

সরাসরি উপরে এন্টারপ্রাইজ দিকটি হাইলাইট করার জন্য +1। দুর্বল লিখিত উত্তরাধিকারের কোডটি পরীক্ষা করা এক সময় দীর্ঘ দিনের দুঃস্বপ্ন হতে পারে।
রিচার্ড লে ম্যাসুরিয়ার

2

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


স্থাপনার? সম্ভবত ... স্থাপনার রক্ষণাবেক্ষণ? সম্ভবত ... কোড রক্ষণাবেক্ষণ? আমার মনে হয় না ... ফ্রেমওয়ার্কের মাধ্যমে ডিবাগ করা বড় মাথা ব্যথা হয়ে থাকে এবং পজোজগুলি সে ক্ষেত্রে কাজ করা অনেক সহজ।
মাইক স্টোন

1
মাইক, আমি কোড সম্পর্কে কিছুই বলেনি। আমরা সকলেই জানি যে এক্সএমএল কনফিগারেশনটি সফল হয় :)
একু

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

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

2

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

<bean id="jane" class="foo.bar.HotFemale">
  <property name="age" value="19"/>
</bean>
<bean id="mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="john" class="foo.bar.Male">
  <property name="girlfriend" ref="jane"/>
</bean>

(উপরোক্ত মহিলা এবং হটফিমেল একই গার্লফ্রেন্ড ইন্টারফেস প্রয়োগ করে)


পুনরায় সংশোধন না করে যুক্তিগত পরিবর্তনগুলি কেন একটি ভাল ধারণা হিসাবে বিবেচিত হয়?
পাভেল ফিল্ডম্যান

আমি অবশ্যই হটফিমেল জেন করতে পারি = নতুন হটফ্যামেল (); jane.setAge (19); john.setGirlfriend (জেন); সুতরাং পার্থক্যটি কি সিএফজি পুনরায় সংশোধন না করে পরিবর্তন করা যায়? বসন্তটি আলোচিত হলে এটি সাধারণ উত্তর বলে মনে হয়। কেন ?! সংকলন এড়ানো ভাল কেন?
পাভেল ফিল্ডম্যান

ঠিক আছে আমি কোডটি আরও ভালভাবে পরীক্ষা করতে পারি আমি মহিলা অবজেক্টটিকে মক করতে পারি।
পল হিলান

@ পাভেল ফিল্ডম্যান: কারণ আপনি যদি ইতিমধ্যে ক্লায়েন্টে অ্যাপ স্থাপন করে থাকেন তবে এটি সহজ।
আন্দ্রে রিনিয়া

1

.NET বিশ্বে, বেশিরভাগ আইওসি ফ্রেমওয়ার্কগুলি এক্সএমএল এবং কোড উভয়ই কনফিগারেশন সরবরাহ করে।

স্ট্রাকচারম্যাপ এবং নিনজেক্ট, উদাহরণস্বরূপ, ধারকগুলি কনফিগার করতে সাবলীল ইন্টারফেস ব্যবহার করুন। আপনি আর এক্সএমএল কনফিগারেশন ফাইলগুলি ব্যবহার করতে বাধা হন না। স্পট, যা। নেট এও বিদ্যমান, এটি XML ফাইলগুলির উপর নির্ভর করে যেহেতু এটি তার historicalতিহাসিক মূল কনফিগারেশন ইন্টারফেস, তবে পাত্রে কনফিগার করার পদ্ধতিটি এখনও সম্ভব program


এটি দুর্দান্ত যে আমি শেষ পর্যন্ত কোডটি ব্যবহার করার উদ্দেশ্যে যা করেছি তার জন্য কোডটি ব্যবহার করতে পারি :) তবে কেন আমি এমনকি এই জাতীয় কাজগুলি করার জন্য প্রোগ্রামিং ভাষা ছাড়াও অন্য কোনও কিছুর প্রয়োজন নেই?
পাভেল ফিল্ডম্যান

আমি মনে করি কারণ এটি XML রানটাইম পরিবর্তনের অনুমতি দেয় বা কমপক্ষে কনফিগারেশন পরিবর্তনের জন্য প্রকল্পটি পুনরায় কম্পাইল না করেই করে।
রোমেন ভার্দিয়ার

1

কর্মের আংশিক কনফিগারেশনের মিশ্রন একটি চূড়ান্ত সম্পূর্ণ কনফিগারেশন মধ্যে।

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

  UI-context.xml
  Model-context.xml
  Controller-context.xml

বা আলাদা UI এবং কয়েকটি অতিরিক্ত নিয়ামক দিয়ে লোড করুন:

  AlternateUI-context.xml
  Model-context.xml
  Controller-context.xml
  ControllerAdditions-context.xml

কোডে একই কাজ করতে আংশিক কনফিগারেশনের সংমিশ্রনের জন্য একটি পরিকাঠামো প্রয়োজন। কোড করা অসম্ভব নয় তবে আইওসি ফ্রেমওয়ার্ক ব্যবহার করে অবশ্যই করা সহজ।


1

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

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


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

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

নির্ভরতা ইনজেকশন ধারকটির মধ্যে তৈরি করা কিছু শ্রেণি পরিবর্তন করার বিষয়ে 'সহায়তা কর্মীরা' কখন জানতে পারবেন ?? সত্যিই অনুমানের অধীনে এটি করা কোনও বিকাশকারীর কাজ?
জিম্বো

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

1

একটি বসন্ত পার্সপসিটিভ থেকে আমি আপনাকে দুটি উত্তর দিতে পারি।

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

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

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


0

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

সম্পত্তি পরিবর্তন হওয়ার কোনও কারণ যদি না থাকে তবে এটিকে কনফিগার করার কোনও কারণও নেই।


0

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

IService myService;
// ...
public void doSomething() {
  myService.fetchData();
}

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

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

0

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


-2

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

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


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

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