Skip to content

পোস্ট

কখন FromService অ্যাট্রিবিউট ব্যবহার করবেন

২০ নভেম্বর, ২০১৯ • 3 মিনিট পড়া

কখন FromService অ্যাট্রিবিউট ব্যবহার করবেন

আমি সম্প্রতি [FromServices] অ্যাট্রিবিউট আবিষ্কার করেছি, যা .Net Core এর প্রথম সংস্করণ থেকেই একটি অংশ।

[FromServices] অ্যাট্রিবিউট Asp.Net Core কন্ট্রোলারে মেথড লেভেল ডিপেন্ডেন্সি ইনজেকশনের সুবিধা প্রদান করে।

এখানে একটি উদাহরণ:

public class UserController : Controller
{
    private readonly IApplicationSettings _applicationSettings;

    public UserController(IApplicationSettings applicationSettings)
    {
        _applicationSettings = applicationSettings;
    }

    public IActionResult Get([FromService]IUserRepository userRepository, int userId)
    {
        //Do magic
    }
}

কনস্ট্রাক্টর ইনজেকশনের পরিবর্তে মেথড ইনজেকশন কেন ব্যবহার করবেন? সাধারণ ব্যাখ্যা হল যখন একটি মেথডের ডিপেন্ডেন্সি প্রয়োজন এবং এটি অন্য কোথাও ব্যবহৃত হয় না, তখন এটি [FromService] অ্যাট্রিবিউট ব্যবহারের জন্য একটি প্রার্থী।

StackOverflow থেকে Steven [FromService] অ্যাট্রিবিউট ব্যবহারের বিপক্ষে একটি উত্তর পোস্ট করেছেন:

আমার জন্য, কন্ট্রোলার অ্যাকশনে এই ধরনের মেথড ইনজেকশনের ব্যবহার একটি খারাপ ধারণা, কারণ:

– এই ধরনের [FromServices] অ্যাট্রিবিউট সহজেই ভুলে যাওয়া যেতে পারে, এবং আপনি শুধুমাত্র তখনই জানতে পারবেন যখন অ্যাকশনটি আহ্বান করা হবে (অ্যাপ্লিকেশন স্টার্ট-আপে জানার পরিবর্তে, যেখানে আপনি অ্যাপ্লিকেশনের কনফিগারেশন যাচাই করতে পারেন)

– পারফরম্যান্সের কারণে কনস্ট্রাক্টর ইনজেকশন থেকে সরে যাওয়ার প্রয়োজন একটি স্পষ্ট ইঙ্গিত যে ইনজেক্ট করা কম্পোনেন্টগুলি তৈরি করতে খুব ভারী, যখন ইনজেকশন কনস্ট্রাক্টরগুলি সহজ হওয়া উচিত, এবং কম্পোনেন্ট তৈরি করা, তাই, খুব হালকা হওয়া উচিত।

– কনস্ট্রাক্টরগুলিকে খুব বড় হওয়া থেকে রোধ করতে কনস্ট্রাক্টর ইনজেকশন থেকে সরে যাওয়ার প্রয়োজন একটি ইঙ্গিত যে আপনার ক্লাসগুলিতে খুব বেশি ডিপেন্ডেন্সি রয়েছে এবং সেগুলি খুব জটিল হয়ে উঠছে। অন্য কথায়, অনেক ডিপেন্ডেন্সি থাকা একটি ইঙ্গিত যে ক্লাসটি Single Responsibility Principle লঙ্ঘন করছে। আপনার কন্ট্রোলার অ্যাকশনগুলি সহজেই বিভিন্ন ক্লাসে বিভক্ত করা যেতে পারে এই সত্যটি প্রমাণ যে এই ধরনের কন্ট্রোলার খুব সংগতিপূর্ণ নয় এবং তাই, একটি SRP লঙ্ঘনের ইঙ্গিত।

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

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

আমি Steven এর সাথে একমত; যদি আপনার ক্লাস খুব বেশি ডিপেন্ডেন্সি তৈরি করার কারণে আপনাকে আপনার ডিপেন্ডেন্সিগুলি কন্ট্রোলার থেকে মেথডে সরাতে হয়, তাহলে কন্ট্রোলারটি ভেঙে ফেলার সময় এসেছে। আপনি প্রায় নিশ্চিতভাবেই SRP লঙ্ঘন করছেন।

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

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

লেখক: চাক কনওয়ে সফটওয়্যার ইঞ্জিনিয়ারিং এবং জেনারেটিভ এআই-তে বিশেষজ্ঞ। তার সাথে সোশ্যাল মিডিয়ায় যোগাযোগ করুন: X (@chuckconway) অথবা তাকে YouTube-এ দেখুন।

↑ উপরে ফিরে যান

আপনি এগুলোও পছন্দ করতে পারেন