এএসপি.নেট এমভিসি - নিয়ন্ত্রকগুলিতে ব্যবসায়ের যুক্তি থাকা উচিত?

Question 1

ডেরিক হুইটেকার কয়েক দিন আগে একটি নিবন্ধ পোস্ট করেছিলেন যা এমন একটি বিন্দুতে আঘাত করে যা আমি কিছু সময়ের জন্য আগ্রহী ছিলাম: নিয়ন্ত্রণকারীদের মধ্যে কি ব্যবসার যুক্তি থাকতে হবে?

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

Question 2

ব্যবসায়ের যুক্তি মডেলটিতে হওয়া উচিত। আপনার চর্বিযুক্ত মডেল, চর্মসার নিয়ন্ত্রণকারীদের লক্ষ্য করা উচিত।

উদাহরণস্বরূপ, পরিবর্তে:

public interface IOrderService{
    int CalculateTotal(Order order);
}

আমি বরং চাই:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

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

এটি আপনার নিয়ামকটিকে এমন কিছু দেখায়:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

বা এমন কিছু।

Question 3

আমি মাইক্রোসফ্ট প্যাটার্নস এবং প্র্যাকটিসগুলি উপস্থাপিত চিত্রটি পছন্দ করি । এবং 'একটি চিত্র হাজার শব্দের মূল্যবান' এই উক্তিটিতে আমি বিশ্বাস করি।

চিত্রটি এমভিসি এবং ব্যবসায়িক সেভিস স্তরগুলির আর্কিটেকচার দেখায়

Question 4

এটি একটি আকর্ষণীয় প্রশ্ন।

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

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

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

Question 5

আপনি স্টিফেন ওয়ালথারের এই দুর্দান্ত টিউটোরিয়ালটি পরীক্ষা করতে পারেন যা কোনও পরিষেবা স্তর দিয়ে যাচাই করা দেখায় ।

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

Question 6

ব্যবসায়িক যুক্তি নিয়ন্ত্রণকারীদের মধ্যে থাকা উচিত নয়। নিয়ন্ত্রকদের যতটা সম্ভব চর্মসার হওয়া উচিত, আদর্শভাবে প্যাটারটিকে অনুসরণ করুন:

ডোমেন সত্তা সন্ধান করুন
ডোমেন সত্তা উপর আইন
ফলাফল / ফলাফলের জন্য ডেটা প্রস্তুত করুন

অতিরিক্তভাবে কন্ট্রোলারগুলিতে কিছু অ্যাপ্লিকেশন যুক্তি থাকতে পারে।

তাহলে আমি আমার ব্যবসার যুক্তি কোথায় রাখি? মডেল ইন।

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

মডেল দেখুন : এটি কেবলমাত্র একটি ডেটা ব্যাগ, নূন্যতম সহ, যদি থাকে তবে, ডেটা থেকে এবং দর্শনগুলিতে পাস করার যুক্তিযুক্ত ক্ষেত্রে, মৌলিক ক্ষেত্রের বৈধতা রয়েছে।
ডোমেন মডেল : ব্যবসায়িক যুক্তিযুক্ত ফ্যাট মডেল, একক বা একাধিক ডেটা সত্তা (যেমন সত্তা বিতে কর্মের চেয়ে প্রদত্ত রাজ্যে সত্তা এ) পরিচালনা করে ope
ডেটা মডেল : স্টোরেজ-সচেতন মডেল, একটি একক সত্তার মধ্যে থাকা যুক্তি কেবলমাত্র সেই সত্তার সাথে সম্পর্কিত (যেমন ক্ষেত্র যদি ক্ষেত্রের ক্ষেত্রে বি ক্ষেত্র হয়)

অবশ্যই, এমভিসি একটি দৃষ্টান্ত যা বিভিন্ন জাতের মধ্যে আসে। আমি এখানে যা বর্ণনা করছি তা কেবল উইকিপিডিয়ায় এই নিবন্ধটি দিয়ে এমভিসি কেবল শীর্ষ স্তর দখল করে

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

Question 7

আপনি যদি নির্ভরতা ইনজেক্টর ব্যবহার করেন তবে আপনার ব্যবসায়ের যুক্তি তাদের কাছে যাবে এবং সেজন্য আপনি ঝরঝরে এবং ক্লিন কন্ট্রোলার পাবেন।