নির্ভরতা ইনজেকশন: ফিল্ড ইনজেকশন বনাম কনস্ট্রাক্টর ইঞ্জেকশন?


61

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

: না হওয়া পর্যন্ত আমি বিভিন্ন ব্লগ (exs আপ পড়া শুরু আমি আমার ক্লাস জন্য একচেটিয়াভাবে ক্ষেত্র ইনজেকশন ব্যবহার করার জন্য ব্যবহৃত petrikainulainen এবং schauderhaft এবং শিকারীদের কন্সট্রাকটর ইনজেকশন সুবিধা সম্পর্কে)। আমি তখন থেকে প্রয়োজনীয় নির্ভরতার জন্য কনস্ট্রাক্টর ইনজেকশন এবং dependচ্ছিক নির্ভরতার জন্য সেটার ইঞ্জেকশন ব্যবহার করার জন্য আমার পদ্ধতিগুলি পরিবর্তন করেছি।

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

আজকের বিশ্বে ইঞ্জেকশন দেওয়ার কি কোন পছন্দনীয় উপায় আছে? ফিল্ড ইনজেকশন পছন্দ হয়?

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



2
আপনি যদি কনস্ট্রাক্টর ইঞ্জেকশন বা সেটার ইঞ্জেকশন ব্যবহারের অনুমতি না পেয়ে থাকেন তবে কীভাবে আপনার নির্ভরতা ক্লাসের হাতে দেওয়ার কথা? মকিত লোকের সাথে আপনার কথোপকথনটি যদি ব্যক্তিগত না করা হয় তবে আপনি বিতর্কের আরও ভাল সংযোগ দিতে পারেন।
রবার্ট হার্ভে

2
@ ডেভিড আর্নো: অপরিবর্তনীয় শ্রেণিতে, রাজ্যটি একবার নির্ধারকের মধ্যে সেট করা হয়
রবার্ট হার্ভে

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

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

উত্তর:


48

ক্ষেত্রের ইনজেকশনটি আমার স্বাদের জন্য কিছুটা "দূরত্বে ভুতুড়ে ক্রিয়া"

আপনি আপনার গুগল গ্রুপ পোস্টে যে উদাহরণটি দিয়েছেন তা বিবেচনা করুন:

public class VeracodeServiceImplTest {


    @Tested(fullyInitialized=true)
    VeracodeServiceImpl veracodeService;
    @Tested(fullyInitialized=true, availableDuringSetup=true)
    VeracodeRepositoryImpl veracodeRepository;
    @Injectable private ResultsAPIWrapper resultsApiWrapper;
    @Injectable private AdminAPIWrapper adminApiWrapper;
    @Injectable private UploadAPIWrapper uploadApiWrapper;
    @Injectable private MitigationAPIWrapper mitigationApiWrapper;

    static { VeracodeRepositoryImpl.class.getName(); }
...
}

সুতরাং মূলত আপনি যা বলছেন তা হ'ল "আমার কাছে এই শ্রেণিটি প্রাইভেট স্টেটের সাথে রয়েছে @injectable, যার সাথে আমি টীকাগুলি সংযুক্ত করেছি , যার অর্থ এই যে রাষ্ট্রটি বাইরের থেকে কোনও এজেন্ট দ্বারা স্বয়ংক্রিয়ভাবে জনবহুল হতে পারে, যদিও আমার রাজ্যটি সমস্ত ব্যক্তিগত হিসাবে ঘোষণা করা হয়েছিল "

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

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

বিকল্পটি বিবেচনা করুন (এটি সি # হতে চলেছে, কারণ আমি এটি আরও ভাল জানি, তবে জাভাতে সম্ভবত একটি সঠিক সমতুল্য রয়েছে):

public class VeracodeService
{        
    private readonly IResultsAPIWrapper _resultsApiWrapper;
    private readonly IAdminAPIWrapper _adminApiWrapper;
    private readonly IUploadAPIWrapper _uploadApiWrapper;
    private readonly IMitigationAPIWrapper _mitigationApiWrapper;

    // Constructor
    public VeracodeService(IResultsAPIWrapper resultsApiWrapper, IAdminAPIWrapper adminApiWrapper, IUploadAPIWrapper uploadApiWrapper,         IMitigationAPIWrapper mitigationApiWrapper)
    {
         _resultsAPIWrapper = resultsAPIWrapper;
         _adminAPIWrapper = adminAPIWrapper;
         _uploadAPIWrapper = uploadAPIWrapper;
         _mitigationAPIWrapper = mitigationAPIWrapper;
    }
}

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

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

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


আমি আপনার পোস্টটি ভুল না পড়লে আপনি আসলে উদাহরণটি সঠিকভাবে দেখছেন না। আমার প্রয়োগটি VeracodeServiceআপনি লেখার মতো প্রায় একই রকম (যদিও জাভা বনাম সি # তে থাকা)। VeracodeServiceImplTestআসলে একটি ইউনিট টেস্ট বর্গ। @Injectableক্ষেত্র মূলত বস্তু প্রসঙ্গ এর দিকে inserted হওয়ার ব্যঙ্গ করছে। @Testedক্ষেত্র দ্বি রচয়িতা সংজ্ঞায়িত সঙ্গে বস্তুর / বর্গ। আমি আপনার দৃষ্টিভঙ্গির সাথে একমত যে ক্ষেত্রের ইনজেকশনের চেয়ে কনস্ট্রাক্টর ইঞ্জেকশন পছন্দ করে। তবে, যেমনটি আমি উল্লেখ করেছি, জেমকিত লেখক এর বিপরীত অনুভব করেছেন এবং আমি কেন তা বোঝার চেষ্টা করছি
এরিক বি।

আপনি যদি সেই আলোচনার প্রথম পোস্টটি দেখেন তবে আপনি দেখতে পাবেন আমার রেপো ক্লাসে আমার প্রায় একই ডিফএন রয়েছে।
এরিক বি।

আপনি যদি কেবল পরীক্ষার ক্লাসের কথা বলছেন তবে তাতে কিছু আসে যায় না। কারণ, পরীক্ষার ক্লাস।
রবার্ট হার্ভে

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

3
+1: হ্যাঁ, সি # সংস্করণে কোনও যাদু নেই। এটি একটি স্ট্যান্ডার্ড ক্লাস, এর নির্ভরতা রয়েছে, ক্লাসটি ব্যবহারের আগে এগুলি সবই এক পর্যায়ে ইনজেকশন দেওয়া হয়। ক্লাসটি ডিআই কনটেইনার সহ ব্যবহার করা যায়, না। শ্রেণীর কিছুই এটি আইওসি বা "স্বয়ংক্রিয় নির্ভরতা ইনজেকশন" কাঠামো বলে না।
বাইনারি ওয়ারিয়ার 13

27

কম পরীক্ষার প্রারম্ভিক বোইলেটপ্লেটের যুক্তিটি বৈধ, তবে অন্যান্য উদ্বেগগুলিও বিবেচনায় নেওয়া উচিত। প্রথমত, আপনাকে একটি প্রশ্নের উত্তর দিতে হবে:

আমি কি চাই যে আমার ক্লাসটি কেবল প্রতিবিম্ব সহ অস্থায়ী হোক?

ক্ষেত্রের ইনজেকশনগুলি ব্যবহার করার অর্থ নির্ভরতা ইনজেকশন পরিবেশে শ্রেণীর সামঞ্জস্যতা সঙ্কুচিত করা যা প্রতিচ্ছবি ব্যবহার করে অবজেক্টগুলিকে ইনস্ট্যান্ট করে এবং এই নির্দিষ্ট ইনজেকশন টীকাগুলিকে সমর্থন করে। জাভা ভাষার উপর ভিত্তি করে কিছু প্ল্যাটফর্ম এমনকি প্রতিবিম্ব ( GWT ) সমর্থন করে না , তাই ক্ষেত্র ‑ ইনজেকশন শ্রেণি তাদের সাথে সামঞ্জস্যপূর্ণ হবে না।

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

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

এই সমস্ত অনেক নতুন প্রশ্ন উত্থাপিত:

  1. অন্য প্ল্যাটফর্মের কোডের অংশগুলি ব্যবহার করার সম্ভাবনা কী?
  2. কত ইউনিট পরীক্ষা লেখা হবে?
  3. প্রতিটি নতুন রিলিজ প্রস্তুত করার জন্য আমার কত দ্রুত প্রয়োজন?
  4. ...

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

ফিল্ড ইনজেকশন বিরুদ্ধে অনেক, অনেক যুক্তি।


3
+1 আপনি একটি স্নায়ু আঘাত। ক্লাস ইনস্ট্যান্ট করার জন্য আমি প্রতিবিম্ব বা একটি ডিআই / আইওসি ফ্রেমওয়ার্কের প্রয়োজন পছন্দ করি না। এটি আমস্টারডাম থেকে প্যারিসে যাওয়ার জন্য রোমে গাড়ি চালানোর মতো। মনে মনে আমি ডিআইকে ভালবাসি। ফ্রেমওয়ার্ক সম্পর্কে ঠিক নিশ্চিত নয়।
মার্জন ভেনেমা

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

19

ফিল্ড ইনজেকশন আমার কাছ থেকে একটি নির্দিষ্ট "না" ভোট পায়।

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

ম্যাকিয়েজ চ্যাপাপুকের মতো, আমি কোনও শ্রেণি ইনস্ট্যান্ট করার জন্য প্রতিবিম্ব বা একটি ডিআই / আইওসি কাঠামোর প্রয়োজন পছন্দ করি না। এটি আমস্টারডাম থেকে প্যারিসে যাওয়ার জন্য রোমে গাড়ি চালানোর মতো।

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

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

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

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


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

1
@hstoerr নিস যাইহোক, এর অর্থ অবশ্যই যে মকিতো প্রতিবিম্ব ব্যবহার করছে (বা এর জাভা সমমানের যাই হোক না কেন) ...
মার্জন ভেনেমা

5

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

সুতরাং, পরিষ্কার হতে হবে:

মাঠের ইনজেকশন:

@Autowired
private SomeService someService;

সেটার ইনজেকশন:

@Autowired
public void setSomeService(SomeService someService) {
    this.someService = someService;
}

তবে, আমার জন্য তারা একই উদ্বেগ ভাগ করে নিচ্ছে। এবং, আমার প্রিয়, কনস্ট্রাক্টর ইঞ্জেকশন:

@AutoWired
public MyService(SomeService someService) {
    this.someService = someService;
}

কনস্ট্রাক্টর ইনজেকশন সেটার / ফিল্ড ইনজেকশনের চেয়ে ভাল (আমার বক্তব্যটি দেখানোর জন্য আমি কিছু স্প্রিং লিঙ্ক উদ্ধৃত করব) বিশ্বাস করার জন্য আমার নিম্নলিখিত কারণ রয়েছে:

  1. বিজ্ঞপ্তি নির্ভরতা রোধ করুন : বসন্ত শিমের মধ্যে বিজ্ঞপ্তি নির্ভরতা সনাক্ত করতে সক্ষম হয়, যেমন @ টমাসজ ব্যাখ্যা করেছেন। আরও দেখুন স্প্রিং টিম বলছে যে।
  2. ক্লাসের নির্ভরতা স্পষ্ট : ক্লাসের নির্ভরতা কন্সট্রাকটর জন্য অতান্ত জরুরি কিন্তু গোপন ক্ষেত্র / সেটার ইনজেকশন সঙ্গে। আমি আমার ক্লাসগুলি ফিল্ড / সেটার ইনজেকশন সহ "ব্ল্যাক বক্স" এর মতো অনুভব করি। এবং (আমার অভিজ্ঞতা অনুসারে) বিকাশকারীদের অনেকগুলি নির্ভরতা সহ ক্লাস সম্পর্কে বিরক্ত করার প্রবণতা নেই, এটি আপনি স্পষ্টরূপে যখন কনস্ট্রাক্টর ইঞ্জেকশন ব্যবহার করে ক্লাসটিকে উপহাস করার চেষ্টা করেন (পরের আইটেমটি দেখুন)। বিকাশকারীদের বিরক্ত করে এমন একটি সমস্যা সম্ভবত সমাধান হওয়ার সম্ভাবনা রয়েছে। এছাড়াও, অনেক বেশি নির্ভরশীলতা সহ একটি শ্রেণি সম্ভবত একক দায়িত্বের নীতি (এসআরপি) লঙ্ঘন করে।
  3. উপহাস করা সহজ এবং নির্ভরযোগ্য : ফিল্ড ইনজেকশনের তুলনায় ইউনিট পরীক্ষায় বিদ্রূপ করা সহজ, কারণ শ্রেণীর অভ্যন্তরে ঘোষিত প্রাইভেট বিনগুলিতে পৌঁছানোর জন্য আপনার কোনও প্রসঙ্গ মক বা প্রতিবিম্ব কারিগরির প্রয়োজন নেই এবং আপনি এটিকে বোকা বানাবেন না । আপনি কেবল ক্লাসটি ইনস্ট্যান্ট করুন এবং উপহাস করা মটরশুটিগুলি পাস করুন। বুঝতে সহজ এবং সহজ।
  4. কোড মানের সরঞ্জামগুলি আপনাকে সহায়তা করতে পারে : সোনারের মতো সরঞ্জামগুলি ক্লাসটি খুব জটিল হওয়ার বিষয়ে আপনাকে সতর্ক করতে পারে, কারণ অনেকগুলি পরামিতি সহ একটি শ্রেণি সম্ভবত একটি জটিল শ্রেণি এবং কিছু রিফ্যাক্টরের প্রয়োজন। ক্লাস ফিল্ড / সেটার ইনজেকশন ব্যবহার করার সময় এই সরঞ্জামগুলি একই সমস্যা চিহ্নিত করতে পারে না।
  5. আরও ভাল এবং স্বতন্ত্র কোড : @AutoWiredআপনার কোডের মধ্যে কম ছড়িয়ে দেওয়ার সাথে সাথে আপনার কোড ফ্রেমওয়ার্কের উপর নির্ভরশীল less আমি জানি যে কোনও প্রকল্পে ডিআই কাঠামোর সহজ পরিবর্তন করার সম্ভাবনাটি ন্যায়সঙ্গত হয় না (কে তা করে, ডান?) তবে এটি আমার কাছে আরও ভাল কোডটি দেখায় (আমি এজেবি এবং লুকআপের সাহায্যে হার্ড পদ্ধতিতে এটি শিখেছি )। এবং স্প্রিংয়ের সাথে আপনি @AutoWiredকনস্ট্রাক্টর ইঞ্জেকশন ব্যবহার করে টিকাও সরিয়ে ফেলতে পারেন ।
  6. আরো টীকা সবসময় সঠিক উত্তর না : জন্য কিছু কারণে , আমি সত্যিই শুধুমাত্র টীকা ব্যবহার করতে যখন তারা সত্যিই দরকারী চেষ্টা করুন।
  7. আপনি ইঞ্জেকশনগুলি পরিবর্তনযোগ্য করতে পারেন । অপরিবর্তনীয়তা একটি খুব স্বাগত বৈশিষ্ট্য।

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

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

এবং কেন তারা বিশ্বাস করে যে কনস্ট্রাক্টর অ্যাপ্লিকেশন কোডের জন্য আরও উপযুক্ত this

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

সর্বশেষ ভাবনা

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

যেহেতু আপনি উভয়, কনস্ট্রাক্টর এবং সেটার ভিত্তিক ডিআই উভয়কে মিশ্রিত করতে পারেন, বাধ্যতামূলক নির্ভরতা এবং tersচ্ছিক নির্ভরতার জন্য সেটটারগুলির জন্য কনস্ট্রাক্টর আর্গুমেন্ট ব্যবহার করা থাম্বের একটি ভাল নিয়ম is

তবে মনে রাখবেন ক্ষেত্রের ইনজেকশনটি সম্ভবত, তিনটির মধ্যে একটি এড়ানো উচিত


-5

আপনার নির্ভরতা কি ক্লাসের জীবদ্দশায় পরিবর্তিত হতে পারে? যদি তাই হয় তবে ক্ষেত্র / সম্পত্তি ইনজেকশন ব্যবহার করুন। অন্যথায় কনস্ট্রাক্টর ইঞ্জেকশন ব্যবহার করুন।


2
এটি আসলে কিছুই ব্যাখ্যা করে না। আপনি যখন তার পরিবর্তে সঠিকভাবে এটি করতে পারেন তখন কেন ব্যক্তিগত ক্ষেত্রগুলি ইনজেক্ট করবেন?
রবার্ট হার্ভে

এটি ব্যক্তিগত ক্ষেত্র সম্পর্কে কোথায় কিছু বলে? আমি / একটি বর্গ পাবলিক ইন্টারফেস বিষয়ে কথা বলছি
ড্যারেন ইয়াং

প্রশ্নে পদ্ধতি ইনজেকশন বনাম কনস্ট্রাক্টর ইঞ্জেকশন সম্পর্কে কোনও যুক্তি নেই। জেমকিতের লেখক দুজনকেই খারাপ হিসাবে দেখেন। প্রশ্নের শিরোনাম দেখুন।
রবার্ট হার্ভে

প্রশ্নটি ফিল্ড ইনজেকশন বনাম কনস্ট্রাক্টর ইঞ্জেকশন বলে না?
ড্যারেন ইয়ং

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