কন্ট্রোলার স্তরে কতটুকু ব্যবসায়ের যুক্তি থাকতে হবে?


39

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

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

এটি কাজ করে, তবে আমি ভাবছি যে এটির বিপর্যয় নিয়ে ফ্লার্টিং কিনা। যদি নিয়ামক এবং মডেলের মধ্যে ব্যবসায়ের যুক্তি ভাগ করা থাকে তবে দুটি স্তর আর পৃথকযোগ্য নয়, এবং কোড উত্তরাধিকার সূত্রে প্রাপ্ত কেউ এই ব্যবসায়িক লজিক সম্পর্কিত কোডের স্থানে এই অসমতায় বিভ্রান্ত হতে পারে।

আমার প্রশ্ন হ'ল নিয়ন্ত্রকের মধ্যে কতটুকু ব্যবসায়ের যুক্তি মঞ্জুর করা উচিত এবং কোন পরিস্থিতিতে, যদি কোনও হয়?


1
দুর্দান্ত প্রশ্ন। আমি মানুষের মতামত দেখার অপেক্ষায় রয়েছি
নাথন টেলর

উত্তর:


20

আদর্শভাবে কেউ না

তবে তা সবসময় সম্ভব হয় না। আমি আপনাকে 20% বা 10 টি লাইনের মতো শক্ত নম্বর দিতে পারি না, এটি তার উত্তর দেওয়া যায় না এমন পয়েন্টের সাপেক্ষে। আমি বর্ণনা করতে পারি যে আমি কীভাবে ডিজাইনের ধরণগুলি এবং পরিস্থিতি ব্যবহার করি যা তাদের সামান্য বাঁকানো প্রয়োজন।

আমার মনে এটি সম্পূর্ণরূপে অ্যাপ্লিকেশনটির উদ্দেশ্য। পোস্ট করার জন্য একটি সাধারণ REST এপিআই তৈরি করছেন? পরিষ্কার বিচ্ছিন্নতা এমনকি একটি প্যাটার্ন সম্পর্কে ভুলে যান। আপনি এক ঘন্টার মধ্যে একটি কার্যকারী সংস্করণ মন্থন করতে পারেন। বড় কিছু তৈরি? এটিতে কাজ করা সম্ভবত সেরা।

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

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

ডিজাইনের ধরণগুলি নমনীয়, আপনার প্রয়োজন অনুসারে এগুলি সামঞ্জস্য করুন । তাদের অত্যধিক বাঁক এবং তারা যদিও বিরতি। আপনার কী প্রয়োজন তা জানুন এবং এর নিকটতম কোনও নকশার প্যাটার্নটি চয়ন করুন।


10

যত কম সম্ভব। সাধারণত কোনটিই নয়।

কন্ট্রোলারের অনুরোধটি গ্রহণের সাথে অনুরোধটি প্রক্রিয়া করার জন্য সঠিক ডোমেন পরিষেবাটি জিজ্ঞাসা করা, এবং সঠিক দর্শনটির প্রতিক্রিয়া বন্ধ করে দেওয়া উচিত।

এই প্রক্রিয়াতে, সমস্ত "ব্যবসায়িক যুক্তি" ডোমেন পরিষেবাগুলিতে থাকা উচিত।

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


10

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

  • ডোমেন লজিক
  • অ্যাপ্লিকেশন লজিক

ডোমেন লজিক হ'ল যুক্ত ক্ষেত্র যা আপনার ব্যবসায়ের সাথে সম্পর্কিত সেই ক্ষেত্রের সাথে সম্পর্কিত, সুতরাং যদি হিসাবরক্ষকদের জন্য আবেদন লিখতে হয় তবে ট্যাক্স বিধি, বই রাখার নিয়ম ইত্যাদি ডোমেন যুক্তির অংশ of

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

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

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


4

নিয়ন্ত্রণকারীদের ডোমেন যুক্তিতে খুব হালকা হওয়া উচিত।

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

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


3

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

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

তৃতীয় বিকল্পটি হ'ল ইউটিলিটি আইটেমগুলিকে পৃথক ইউটিলিটি শ্রেণি হিসাবে উল্লেখ করা হবে, তবে এটি অনেকের মতে প্যাটার্নের বিরুদ্ধেও somewhat

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

এমভিসি হ'ল এক পর্যায়ে প্রতিষ্ঠিত নিদর্শন থেকে বিচ্যুতি।


3

প্রোগ্রামিংয়ের অন্যান্য আকর্ষণীয় ধারণার মতো, এমভিসি একটি দৃশ্যের বাস্তবায়ন করার জন্য ঘনিষ্ঠ বা অনুরূপ কৌশলগুলির পরিবারকে কাঠামো আনতে এবং মনোনিবেশ করার জন্য একটি শক্তিশালী দৃষ্টান্ত।

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

তবুও, অন্যান্য অনেক প্রোগ্রামিং ধারণার মতো, এমভিএস হ'ল বাস্তবের সরলিকরণ। এটি নিখুঁত নয় এবং এটি সম্পূর্ণ নয়। একারণেই বাস্তব জগতের দৃশ্যের ওভারসিম্প্লিফাইড মডেলটিতে ফিট করা সম্ভব নয়। সুতরাং এটি একটি অনুরূপ অনেক প্রশ্ন উত্থাপন।

  • একটি নিয়ামক মধ্যে কত যুক্তি করা উচিত?

  • দৃশ্যে কোনও শর্তযুক্ত যুক্তি থাকা উচিত কিনা?

  • কোনও মডেলটিতে এমন কোনও অতিরিক্ত ডেটা থাকা উচিত যা ব্যবসায়ের সত্তায় সরাসরি পাওয়া যায় না?

এমভিসির ধারণা এবং ধারণাটি সঠিকভাবে এবং সম্পূর্ণরূপে ফিট করার জন্য কোডটি সামঞ্জস্য করার প্রয়াসেই এগুলি সমস্ত প্রশ্ন born

আপনার আমার উত্তরটি চেষ্টা করার দরকার নেই। এমভিসি কাঠামো সরবরাহ করে। এই ভিত্তিটির চারপাশে আপনার অ্যাপ্লিকেশনটি তৈরি করুন তবে এটি পুরোপুরি ফিট হওয়ার আশা করবেন না। বিচ্যুতি হবে, এটি স্বাভাবিক। এগুলি নিয়ন্ত্রণে রাখতে কেবল দেখুন watch

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