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] অ্যাট্রিবিউট ব্যবহারের জন্য একটি প্রার্থী।

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

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

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

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

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

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

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

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

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

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

লেখক: চাক কনওয়ে একজন এআই ইঞ্জিনিয়ার যার কাছে প্রায় ৩০ বছরের সফটওয়্যার ইঞ্জিনিয়ারিং অভিজ্ঞতা রয়েছে। তিনি ব্যবহারিক এআই সিস্টেম তৈরি করেন—কন্টেন্ট পাইপলাইন, অবকাঠামো এজেন্ট এবং সরঞ্জাম যা বাস্তব সমস্যার সমাধান করে—এবং তার শেখার বিষয়গুলি শেয়ার করেন। তার সাথে সোশ্যাল মিডিয়ায় সংযোগ করুন: X (@chuckconway) অথবা তাকে YouTube এবং SubStack এ দেখুন।

↑ শীর্ষে ফিরে যান

আপনি এটিও পছন্দ করতে পারেন