এমভিসি-তে ব্যবসায়ের যুক্তি [বন্ধ]
উত্তর:
ব্যবসায়ের নিয়মগুলি মডেলটিতে যায়।
বলুন আপনি কোনও মেলিং তালিকার জন্য ইমেল প্রদর্শন করছেন। ব্যবহারকারী ইমেলগুলির একটির পাশের "মুছুন" বোতামটি ক্লিক করে, নিয়ামকটি এনড্রি এন মোছার জন্য মডেলকে অবহিত করে, তারপরে মডেলটি পরিবর্তিত হয়েছে বলে জানায়।
সম্ভবত অ্যাডমিনের ইমেলটি কখনই তালিকা থেকে সরানো উচিত নয়। এটি একটি ব্যবসায়ের নিয়ম, সেই জ্ঞানটি মডেলটির অন্তর্ভুক্ত। দৃশ্যটি চূড়ান্তভাবে কোনওভাবে এই নিয়মকে উপস্থাপন করতে পারে - সম্ভবত মডেলটি একটি "ইসডলেটযোগ্য" সম্পত্তি প্রকাশ করে যা ব্যবসায়ের নিয়মের একটি ফাংশন, যাতে ভিউতে মুছুন বোতামটি নির্দিষ্ট এন্ট্রিগুলির জন্য অক্ষম থাকে - তবে নিয়মটি নিজেই এতে অন্তর্ভুক্ত থাকে না দেখুন মধ্যে.
মডেলটি শেষ পর্যন্ত আপনার ডেটার জন্য দারোয়ান। আপনার ইউআইআইয়ের স্পর্শ না করে আপনার ব্যবসায়ের যুক্তি পরীক্ষা করতে সক্ষম হওয়া উচিত।
সকলের মুষ্টি:
আমি বিশ্বাস করি যে আপনি এমভিসি প্যাটার্ন এবং এন-স্তর-ভিত্তিক নকশার নীতিগুলি মিশ্রণ করছেন।
এমভিসি পদ্ধতির ব্যবহারের অর্থ এই নয় যে আপনার অ্যাপ্লিকেশনটি স্তরযুক্ত করা উচিত নয়।
আপনি এমভিসি আরও উপস্থাপনা স্তরটির এক্সটেনশনের মতো দেখতে পান এটি আপনাকে সহায়তা করতে পারে।
আপনি যদি এমভিসি প্যাটার্নের ভিতরে নন-প্রেজেন্টেশন কোডটি রাখেন তবে খুব তাড়াতাড়ি আপনি একটি জটিল ডিজাইনে শেষ করতে পারেন।
অতএব আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি আপনার ব্যবসায়িক যুক্তিটিকে একটি পৃথক ব্যবসায়ের স্তরে রাখবেন।
এটি একবার দেখুন: মাল্টিটায়ার আর্কিটেকচার সম্পর্কে উইকিপিডিয়া নিবন্ধ
এটি বলে:
আজ, এমভিসি এবং অনুরূপ মডেল-ভিউ-উপস্থাপক (এমভিপি) কনসার্নস ডিজাইনের ধরণগুলির পৃথকীকরণ যা কোনও বৃহত সিস্টেমের উপস্থাপনা স্তরটিতে একচেটিয়াভাবে প্রযোজ্য ।
যাইহোক ... কোনও এন্টারপ্রাইজ ওয়েব অ্যাপ্লিকেশন সম্পর্কে কথা বলার সময় UI থেকে ব্যবসায়িক লজিক স্তরটিতে কলগুলি (উপস্থাপনা) নিয়ামকের ভিতরে রাখা উচিত।
এজন্য যে কন্ট্রোলার প্রকৃতপক্ষে একটি নির্দিষ্ট সংস্থানটিতে কলগুলি পরিচালনা করে, ব্যবসায়িক যুক্তিতে কল করে ডেটা অনুসন্ধান করে এবং ডেটা (মডেল )টিকে উপযুক্ত দৃশ্যের সাথে সংযুক্ত করে।
কাদা আপনাকে জানিয়েছিল যে ব্যবসায়ের নিয়মগুলি মডেলটিতে চলে।
এটিও সত্য, তবে তিনি (উপস্থাপনা) মডেল (এমভিসিতে 'এম') এবং একটি স্তর-ভিত্তিক অ্যাপ্লিকেশন ডিজাইনের ডেটা স্তর মডেলটি মিশ্রিত করেছেন।
সুতরাং আপনার অ্যাপ্লিকেশনটির মডেল (ডেটা স্তর) এ আপনার ডাটাবেস সম্পর্কিত ব্যবসায়ের নিয়ম স্থাপন করা বৈধ ।
তবে আপনার এগুলিকে আপনার এমভিসি-কাঠামোগত উপস্থাপনা স্তরটির মডেলে স্থাপন করা উচিত নয় কারণ এটি কেবলমাত্র একটি নির্দিষ্ট ইউআইতে প্রযোজ্য।
এই কৌশলটি আপনি কোনও ডোমেন চালিত ডিজাইন বা লেনদেনের স্ক্রিপ্ট ভিত্তিক পদ্ধতির ব্যবহার করেন কিনা তা থেকে স্বাধীন।
আমাকে আপনার জন্য এটি কল্পনা করতে দিন:
উপস্থাপনা স্তর: মডেল - দেখুন - নিয়ামক
ব্যবসায়ের স্তর: ডোমেন যুক্তি - অ্যাপ্লিকেশন যুক্তি
ডেটা স্তর: ডেটা সংগ্রহস্থল - ডেটা অ্যাক্সেস স্তর
আপনি উপরে যে মডেলটি দেখছেন তার অর্থ হল আপনার কাছে এমন একটি অ্যাপ্লিকেশন রয়েছে যা এমভিসি, ডিডিডি এবং একটি ডাটাবেস-স্বতন্ত্র ডেটা স্তর ব্যবহার করে।
বৃহত্তর এন্টারপ্রাইজ ওয়েব অ্যাপ্লিকেশনটি ডিজাইনের জন্য এটি একটি সাধারণ পদ্ধতি।
তবে আপনি এটি একটি সাধারণ নন-ডিডিডি ব্যবসায় স্তর (ডোমেন যুক্তিবিহীন একটি ব্যবসায় স্তর) এবং একটি নির্দিষ্ট ডেটাবেসে সরাসরি লেখেন এমন একটি সাধারণ ডেটা স্তর ব্যবহার করতে এটি সঙ্কুচিতও করতে পারেন।
এমনকি আপনি পুরো ডেটা স্তরটি ফেলে দিতে পারেন এবং ব্যবসায়ের স্তর থেকে সরাসরি ডাটাবেস অ্যাক্সেস করতে পারেন, যদিও আমি এটি প্রস্তাব করি না।
কৌশলটি ... আমি আশা করি এটি সাহায্য করবে ...
[দ্রষ্টব্য:] আপনার এই বিষয়টি সম্পর্কেও সচেতন হওয়া উচিত যে আজকাল একটি অ্যাপ্লিকেশনটিতে কেবলমাত্র একটি "মডেল" রয়েছে। সাধারণত, একটি অ্যাপ্লিকেশন প্রতিটি স্তর এর নিজস্ব মডেল আছে। উপস্থাপনা স্তরটির মডেলটি দেখতে নির্দিষ্ট তবে প্রায়শই ব্যবহৃত নিয়ন্ত্রণগুলির চেয়ে পৃথক। ব্যবসায় স্তরটিতে একটি মডেলও থাকতে পারে, যাকে "ডোমেন-মডেল" বলা হয়। আপনি যখন কোনও ডোমেন-চালিত পদ্ধতির সিদ্ধান্ত নেওয়ার সিদ্ধান্ত নেন তখন এটি সাধারণত হয়। এই "ডোমেন-মডেল" তে ডেটা পাশাপাশি ব্যবসায়িক যুক্তি (আপনার প্রোগ্রামের মূল যুক্তি) থাকে এবং সাধারণত উপস্থাপনা স্তর থেকে পৃথক থাকে। উপস্থাপনা স্তর সাধারণত একটি নির্দিষ্ট "ইভেন্ট" (বোতাম টিপানো ইত্যাদি) তে ব্যবসায় স্তরকে ডেটা স্তর থেকে ডেটা পড়তে বা লিখতে কল করে। ডেটা স্তরটির নিজস্ব মডেলও থাকতে পারে যা সাধারণত ডাটাবেস সম্পর্কিত।
প্রশ্নটি: এমভিসি ধারণাটিতে এটি কীভাবে খাপ খায়?
উত্তর -> না!
ঠিক আছে - এটি কিন্ডা করে তবে পুরোপুরি হয় না।
এটি কারণ এমভিসি হ'ল একটি দৃষ্টিভঙ্গি যা ১৯ late০ এর দশকের শেষদিকে স্মার্টটাক -৮০ প্রোগ্রামিং ভাষার জন্য তৈরি হয়েছিল। সেই সময় জিইউআই এবং ব্যক্তিগত কম্পিউটারগুলি বেশ অস্বাভাবিক ছিল এবং ওয়ার্ল্ড ওয়াইড ওয়েবও আবিষ্কার হয়নি! আজকের বেশিরভাগ প্রোগ্রামিং ভাষা এবং আইডিই 1990 এর দশকে তৈরি হয়েছিল। সেই সময় কম্পিউটার এবং ইউজার ইন্টারফেসগুলি 1970 এর দশকের থেকে সম্পূর্ণ আলাদা ছিল।
আপনি যখন এমভিসি সম্পর্কে কথা বলেন তখন আপনার তা মনে রাখা উচিত।
মার্টিন ফাউলর এমভিসি, এমভিপি এবং আজকের জিইউআই সম্পর্কে একটি খুব ভাল নিবন্ধ লিখেছেন।
শব্দ যুক্তি শব্দটি আমার মতে একটি নির্দিষ্ট সংজ্ঞা নয়। ইভান্স তার বই, ডোমেন ড্রাইভেন ডিজাইনে প্রায় দুই ধরণের ব্যবসায়িক যুক্তি নিয়ে আলোচনা করেছে:
- ডোমেন যুক্তি।
- প্রয়োগ যুক্তি।
এই বিচ্ছেদটি আমার মতে অনেক পরিষ্কার। এবং বিভিন্ন ধরণের ব্যবসায়ের নিয়ম রয়েছে এমন উপলব্ধির সাথে উপলব্ধিও আসে যে তারা অগত্যা একই জায়গায় যায় না।
ডোমেন যুক্তি যুক্তি যা আসল ডোমেনের সাথে মিলে যায়। সুতরাং যদি আপনি কোনও অ্যাকাউন্টিং অ্যাপ্লিকেশন তৈরি করে থাকেন তবে ডোমেনের বিধিগুলি অ্যাকাউন্ট, পোস্টিং, কর আদায় ইত্যাদির বিষয়ে নিয়ম হতে পারে software প্রভৃতি
এই উভয় প্রকারের প্রয়োগের জন্যই সিএসভি আমদানি / রফতানি প্রাসঙ্গিক হতে পারে তবে সিএসভি আমদানি / রফতানির নিয়মের প্রকৃত ডোমেনের সাথে কোনও সম্পর্ক নেই। এ জাতীয় যুক্তি হ'ল অ্যাপ্লিকেশন লজিক।
ডোমেন লজিক অবশ্যই মডেল স্তরের মধ্যে যায়। মডেলটি ডিডিডিতে ডোমেন স্তরের সাথেও মিল রাখে।
অ্যাপ্লিকেশন যুক্তি অবশ্য প্রয়োজন হয় না মডেল স্তরে স্থাপন করা। এটি সরাসরি নিয়ন্ত্রকদের মধ্যে স্থাপন করা যেতে পারে, বা আপনি এই বিধিগুলি হোস্টিংয়ের জন্য একটি পৃথক অ্যাপ্লিকেশন স্তর তৈরি করতে পারেন। এক্ষেত্রে সবচেয়ে যুক্তিযুক্ত কি তা নির্ভরযোগ্য প্রয়োগের উপর নির্ভর করবে।
এ 1 : বিজনেস লজিক Modelঅংশ নিতে যায় MVC। ভূমিকা Modelহ'ল ডেটা এবং ব্যবসায়ের যুক্তি ধারণ করে। Controllerঅন্যদিকে ব্যবহারকারীর ইনপুট গ্রহণ এবং কী করবেন তা সিদ্ধান্ত নিতে দায়বদ্ধ।
এ 2 : এ এর Business Ruleএকটি অংশ Business Logic। তাদের একটা has aসম্পর্ক আছে। Business Logicহয়েছে Business Rules।
একবার দেখুন Wikipedia entry for MVC। ওভারভিউতে যান যেখানে এটি প্রবাহের উল্লেখ করেMVC প্যাটার্নের ।
এছাড়াও দেখুন Wikipedia entry for Business Logic। এটি এবং এর Business Logicসমন্বয়ে উল্লেখ করা হয়েছে ।Business RulesWorkflow
বেশ কয়েকটি উত্তর যেমন উল্লেখ করেছে, আমি বিশ্বাস করি যে এমভিসি আর্কিটেকচার বনাম মাল্টি টায়ারের কিছু ভুল ধারণা রয়েছে।
মাল্টি টায়ার আর্কিটেকচারে আপনার অ্যাপ্লিকেশনটিকে স্তর / স্তরগুলিতে ভাঙ্গা জড়িত (যেমন উপস্থাপনা, ব্যবসায়িক যুক্তি, ডেটা অ্যাক্সেস)
এমভিসি একটি অ্যাপ্লিকেশনটির উপস্থাপনা স্তরটির জন্য একটি স্থাপত্য শৈলী। অপ্রয়োজনীয় অ্যাপ্লিকেশনগুলির জন্য, ব্যবসায়িক যুক্তি / ব্যবসায়িক বিধি / ডেটা অ্যাক্সেস সরাসরি মডেল, দর্শন বা কন্ট্রোলারগুলিতে স্থাপন করা উচিত নয়। এটি করার জন্য আপনার উপস্থাপনা স্তরে ব্যবসায়িক যুক্তি স্থাপন করা এবং এভাবে আপনার কোডের পুনরায় ব্যবহার এবং রক্ষণাবেক্ষণ হ্রাস করা হবে।
ব্যবসায়ের যুক্তি স্থাপনের জন্য মডেলটি একটি খুব যুক্তিসঙ্গত পছন্দ, তবে আরও ভাল / আরও রক্ষণাবেক্ষণের উপায় হল আপনার প্রেজেন্টেশন স্তরটিকে আপনার ব্যবসায়িক লজিক স্তর থেকে আলাদা করা এবং একটি ব্যবসায়িক লজিক স্তর তৈরি করা এবং যখন প্রয়োজন হয় তখন কেবল আপনার মডেলগুলি থেকে ব্যবসায়িক লজিক স্তরকে কল করুন। ব্যবসায়ের যুক্তিযুক্ত স্তরটি পরিবর্তে ডেটা অ্যাক্সেস স্তরে কল করবে।
আমি উল্লেখ করতে চাই যে এমভিসি উপাদানগুলির মধ্যে একটিতে ব্যবসায়িক যুক্তি এবং ডেটা অ্যাক্সেসের মিশ্রিত কোড খুঁজে পাওয়া অস্বাভাবিক নয়, বিশেষত যদি অ্যাপ্লিকেশনটি একাধিক স্তর ব্যবহার করে আর্কিটেটেড না করা হত। তবে, বেশিরভাগ এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলিতে, আপনি সাধারণত উপস্থাপনা স্তরের স্থলে এমভিসি আর্কিটেকচার সহ বহু স্তরের আর্কিটেকচার পাবেন।
এটি একটি উত্তর দেওয়া প্রশ্ন, তবে আমি আমার "এক শতাংশ" দেব:
ব্যবসায়ের নিয়মগুলি মডেলটির অন্তর্ভুক্ত। "মডেল" সর্বদা গঠিত (যৌক্তিক বা শারীরিকভাবে পৃথক):
- উপস্থাপনা মডেল - শ্রেণীর একটি সেট যা দৃষ্টিতে ব্যবহারের জন্য উপযুক্ত (এটি নির্দিষ্ট ইউআই / উপস্থাপনার জন্য উপযুক্ত),
- ডোমেন মডেল - মডেলের UI- স্বতন্ত্র অংশ এবং
- সংগ্রহস্থল - "মডেল" এর স্টোরেজ-সচেতন অংশ।
ব্যবসায়ের বিধিগুলি ডোমেন মডেলটিতে লাইভ থাকে, "উপস্থাপনা" মডেলটিতে উপস্থাপনা-উপযুক্ত আকারে প্রকাশিত হয় এবং কখনও কখনও "ডেটা স্তর" তে নকল হয় (বা প্রয়োগ করা হয়)।
এমভিসি প্রকল্পের জন্য আপনার ব্যবসায়ের স্তরটিকে মডেলটিতে রাখার অর্থ নেই।
বলুন যে আপনার বস উপস্থাপনা স্তরটি অন্য কোনওটিতে পরিবর্তন করার সিদ্ধান্ত নিয়েছে, আপনি বিচলিত হবেন! ব্যবসায়ের স্তরটি একটি পৃথক সমাবেশ হতে হবে। একটি মডেলটিতে এমন ডেটা থাকে যা ব্যবসায়ের স্তর থেকে আসে যা প্রদর্শন করতে ভিউতে যায়। তারপরে পোস্টের উদাহরণস্বরূপ, মডেলটি এমন একটি ব্যক্তি শ্রেণীর সাথে আবদ্ধ হয় যা ব্যবসায়ের স্তরটিতে থাকে এবং পার্সনবসনেসকে বলে ave সেভপারসন (পি); যেখানে p হচ্ছে ব্যক্তি শ্রেণি। আমি যা করি তা এখানে রয়েছে (বিজনেসআরারের ক্লাসটি অনুপস্থিত তবে এটি বিজনেস লাইয়ারেও যাবে):
চতুর্থাংশ 1:
ব্যবসায়িক যুক্তিগুলি দুটি বিভাগে বিবেচনা করা যেতে পারে:
ইমেল ঠিকানার (স্বতন্ত্রতা, সীমাবদ্ধতা ইত্যাদির) নিয়ন্ত্রণ, চালানের জন্য কোনও পণ্যের দাম অর্জন করা বা শপিংকার্টের পণ্য সামগ্রীর উপর ভিত্তি করে মোট মূল্য নির্ধারণের মতো ডোমেন লজিক্স controls
আরও বিস্তৃত এবং জটিল ওয়ার্কফ্লোগুলি যাকে ব্যবসায়িক প্রক্রিয়া বলা হয়, যেমন শিক্ষার্থীর নিবন্ধকরণ প্রক্রিয়া নিয়ন্ত্রণ করা (যার মধ্যে সাধারণত বেশ কয়েকটি পদক্ষেপ থাকে এবং বিভিন্ন চেকের প্রয়োজন হয় এবং আরও জটিল বাধা থাকে) has
প্রথম বিভাগ মধ্যে যায় মডেল এবং দ্বিতীয় এক জন্যে নিয়ামক । এটি কারণ দ্বিতীয় বিভাগের ক্ষেত্রে বিস্তৃত অ্যাপ্লিকেশন লজিক এবং মডেলগুলিতে রাখলে মডেলটির বিমূর্ততা মিশ্রিত হতে পারে (উদাহরণস্বরূপ, আমাদের যদি সিদ্ধান্তগুলি একটি মডেল শ্রেণিতে বা অন্যটিতে রাখার প্রয়োজন হয় তবে এটি পরিষ্কার নয় যেহেতু তারা সম্পর্কিত) উভয়!)।
এই দেখুন উত্তর মডেল এবং নিয়ামক মধ্যে একটি নির্দিষ্ট পার্থক্য জন্য, এই লিঙ্কে খুব সঠিক সংজ্ঞা এবং এই লিংক একটা চমৎকার অ্যান্ড্রয়েড উদাহরণস্বরূপ।
মুল বক্তব্যটি হ'ল "মুড" এবং "ফ্রাঙ্ক" উভয়ের উপরে উল্লিখিত নোটগুলি পাশাপাশি "পিট" এর (ব্যবসায়িক যুক্তির ধরণ অনুসারে মডেল বা নিয়ন্ত্রণকারীতে ব্যবসায়ের যুক্তি স্থাপন করা যেতে পারে) সত্য হতে পারে।
পরিশেষে, দ্রষ্টব্য যে এমভিসি প্রসঙ্গে থেকে প্রসঙ্গে আলাদা। উদাহরণস্বরূপ, অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলিতে, কিছু বিকল্প সংজ্ঞা দেওয়া হয় যা ওয়েব-ভিত্তিকগুলি থেকে পৃথক হয় ( উদাহরণস্বরূপ এই পোস্টটি দেখুন )।
Q2 এর:
ব্যবসায়ের যুক্তি আরও সাধারণ এবং (উপরে উল্লিখিত "ডেস্ক্লোন" হিসাবে) আমাদের মধ্যে তাদের মধ্যে নিম্নলিখিত সম্পর্ক রয়েছে:
ব্যবসায়িক বিধি ⊂ ব্যবসায়িক লজিক
আপনি কেন কোনও পরিষেবা স্তর প্রবর্তন করবেন না। তারপরে আপনার নিয়ামক হাতা এবং আরও পঠনযোগ্য হয়ে উঠবে, তারপরে আপনার সমস্ত নিয়ামক ক্রিয়াকলাপ বিশুদ্ধ ক্রিয়া হবে। আপনি পরিষেবা স্তর মধ্যে আপনার প্রয়োজন হিসাবে ব্যবসায়িক যুক্তি আপনি পচন করতে পারেন। কোড পুনরায় ব্যবহারযোগ্যতা হাইট হয়। মডেল এবং সংগ্রহস্থলের উপর কোনও প্রভাব ফেলবে না।
মডেল = CRUD ডাটাবেস ক্রিয়াকলাপের কোড।
কন্ট্রোলার = ব্যবহারকারীর ক্রিয়াতে সাড়া দেয় এবং কোনও সংস্থার সাথে সম্পর্কিত ব্যবসায়িক বিধি সাপেক্ষে তথ্য পুনরুদ্ধার বা মডেলটিকে মুছুন / আপডেট করার জন্য ব্যবহারকারীদের অনুরোধগুলি পাস করে। এই ব্যবসার বিধিগুলি সহায়ক শ্রেণিতে প্রয়োগ করা যেতে পারে, বা এগুলি খুব জটিল না হলে কেবল সরাসরি নিয়ামক পদক্ষেপে। নিয়ামক শেষ পর্যন্ত ভিউটিকে নিজের আপডেট করতে বলে যাতে কোনও নতুন ডিসপ্লে আকারে ব্যবহারকারীকে প্রতিক্রিয়া জানাতে বা 'আপডেটেড, থ্যাঙ্কস' ইত্যাদির মতো একটি বার্তা দেয়,
মডেলটির একটি ক্যোয়ারির ভিত্তিতে উত্পন্ন উত্স = ইউআই।
ব্যবসায়ের নিয়মগুলি কোথায় যাওয়া উচিত সে সম্পর্কে কোনও কঠোর এবং দ্রুত নিয়ম নেই। কিছু ডিজাইনে তারা মডেলে চলে যায়, অন্যদিকে তারা নিয়ামকের সাথে অন্তর্ভুক্ত থাকে। তবে আমি তাদের নিয়ন্ত্রণকারীর সাথে রাখা ভাল বলে মনে করি। মডেলটিকে কেবল ডাটাবেস সংযোগ সম্পর্কে উদ্বেগ জানাতে দিন।