মডেলটিতে ব্যবসায়ের যুক্তি রাখবেন কেন? আমার একাধিক ধরণের সঞ্চয়স্থান থাকলে কী হবে?


70

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

এখন আমি এই প্রশ্নে পড়েছি আপনার ব্যবসায়ের যুক্তিটি সর্বদা মডেলটিতে রাখা উচিত এবং নিয়ামকটি দৃশ্যের সাথে গভীরভাবে যুক্ত।

আমার কাছে, এটি সত্যিকার অর্থে বোঝা যায় না এবং বোঝায় যে প্রতিবার আমি অন্য ডেটাবেস / স্টোরেজকে সমর্থন করার উপায়টি পেতে চাই আমি ব্যবসার যুক্তি সহ আমার পুরো মডেলটি আবার লিখি।

এবং আমি যদি অন্য একটি ভিউ চাই, আমাকে ভিউ এবং নিয়ামক উভয়ই আবার লিখতে হবে।

কেউ ব্যাখ্যা করতে পারেন যে এটি কেন বা আমি কোথাও ভুল হয়ে গেলে?

উত্তর:


69

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

দুটি স্পষ্টতা:

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

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

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

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

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

1
@ ফ্লিপডুব্ট বিজনেস লজিক এমন কোনও যুক্তি যা আপনি একইভাবে রাখা উচিত যদি আপনি এমভিসি থেকে কোনও ইউপিপি অ্যাপ্লিকেশন বলতে পোর্ট করেন।
অ্যান্ডি

23

আপনি এবং প্রোগ্রামিং জগতের বড় অংশগুলি এমভিসি অংশগুলির ভূমিকা কী তা ভুল বোঝে। সংক্ষেপে, তারা হ'ল:

মডেল = ডোমেন যুক্তি

দেখুন = আউটপুট যুক্তি

নিয়ামক = ইনপুট যুক্তি

এর অর্থ হ'ল মডেলটি পুরো ব্যবসায়ের যুক্তির জন্য দায়ী: যে কোনও কিছু যা কোনও স্ক্রিনে উইজেট আঁকার সাথে সম্পর্কিত, একটি প্রিন্টার চালনা, এইচটিএমএল হিসাবে ডেটা আউটপুট আউট করা, এইচটিটিপি অনুরোধ পার্সিং ইত্যাদি ইত্যাদি মডেলের অন্তর্ভুক্ত নয়।

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

আপনি মাল্টি-টিয়ার আর্কিটেকচার সম্পর্কেও পড়তে চাইতে পারেন; যেখানে এমভিসি এক ধরণের (প্রবাহটি নিয়ন্ত্রক -> মডেল -> দেখুন), মাল্টি-টিয়ার একটি দ্বিমুখী জিনিস (উপস্থাপনা -> লজিক -> ডেটা -> লজিক -> উপস্থাপনা) এবং বেশ কয়েকটি এমভিসি করার ভান করে এমন কাঠামো প্রকৃতপক্ষে থ্রি-টায়ার করে, দেখার জন্য উপস্থাপনা সম্পর্কিত, লজিক থেকে নিয়ন্ত্রণকারী এবং ডেটা টু মডেল।


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

@ এ। মুর্য: অবশ্যই মডেলটির কোনও একক একক ব্লব হতে হবে না এবং এটিকে অধ্যবসায়, ডেটা স্ট্রাকচার এবং ডোমেন লজিকের মধ্যে আলাদা করা সাধারণত প্রচুর অর্থবোধ করে। তবুও, এমভিসি মডেলটিতে এই তিনটি উদ্বেগকে একত্রিত করে। যাইহোক, যখন আপনার নিয়ামক এবং দর্শনগুলিতে ডোমেন যুক্তি থাকে, তখন এটি আর আসল এমভিসি থাকে না।
tdammers

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

15

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

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

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

হালনাগাদ

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

ষড়ভুজ আর্কিটেকচারে, একটি এমভিসি উপস্থাপনা স্তরটি আপনার ডোমেন মডেল (ব্যবসায়িক যুক্তি) এবং একটি জিইউআইয়ের মধ্যে একটি অ্যাডাপ্টার। ডোমেন মডেল উপস্থাপনা স্তর সম্পর্কে সচেতন নয়, তবে উপস্থাপনা স্তরটি ডোমেন মডেল সম্পর্কে সচেতন।

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


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

সত্যি কথা বলতে, আমি ওয়াওকের উত্তরটি আরও পছন্দ করি। মূলত কারণ 'অ্যাপ্লিকেশন পরিষেবাদি' দিয়ে আপনি কী বোঝাতে চেয়েছেন তা সম্পর্কে আমার কোনও ধারণা নেই। আপনি কি এই শব্দটি ব্যাখ্যা করতে পারেন? আমার গুগলএফইউ এখানে যেমন কাজ করছে তেমন কাজ করছে না।
স্টিফেন উইঙ্কলার

1
@ ওয়াওকো আমি সম্মত হই যে প্রস্তাবিত আর্কিটেকচার ওভারকিল হতে পারে, তবে এটি বিবেচনা করা উচিত। আমি এমভিভিএমের কোনও উল্লেখ করি নি যা উপস্থাপনা স্তরটি কার্যকর করার অন্য উপায়। আপনি এমভিসি বা এমভিভিএম ব্যবহার করেন না কেন এবং আমি প্রস্তাবিত কিছুই এই দুটির সংমিশ্রণ নির্দেশ করে না তা বিবেচনা না করেই অ্যাপ্লিকেশন পরিষেবাগুলি প্রযোজ্য।
eulerfx

1

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

মডেলটিতে "ব্যবসায়িক যুক্তি" স্থাপন না করে আমি একবার একবার রেলের স্রষ্টা (আমার মনে করি) এর এক উদাহরণ দেখেছি exactly অ্যাপ্লিকেশন নিবন্ধকরণ এবং লগইন করার জন্য তার উদাহরণ ছিল একটি নিয়ন্ত্রক শ্রেণি এবং পদ্ধতি - সাদামাটা প্লেটে সরবরাহ করা পাসওয়ার্ডটি মডেলটির ভিতরে প্রবেশ বা জিজ্ঞাসা করার আগে এনক্রিপ্ট করা হয়েছিল (একটি ডাটাবেস))

আমি এমন কোনওরকমের আরও ভাল উদাহরণের কথা ভাবতে পারি না যা নিয়ামক যুক্তি নয় এবং এটি সরাসরি মডেলটির সাথে সম্পর্কিত।

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

সাধারণভাবে বলতে গেলে, কন্ট্রোলার মডেলটি এবং ভিউটিকে সংযুক্ত করে (যা অ্যাপ্লিকেশনের মাংস-আলু।

এমভিসি-তে জিওএফের "ডিজাইন প্যাটার্নস" বিভাগটি শিথিলভাবে উদ্ধৃত হয়েছে:

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

এমভিসি সমস্ত ইউআই সম্পর্কে s ফোকাসটি মডেলটিতে রয়েছে এবং দেখুন - ডেটা সংজ্ঞায়িত করা এবং প্রদর্শন করা। "সাবস্ক্রাইব / বিজ্ঞপ্তি প্রোটোকল" নোট করুন - এটিই যেখানে আপনার নিয়ামক আসে। আপনি যা চান তার সব মতামত তৈরি করতে পারেন; এতক্ষণ তারা প্রোটোকল মেনে চললে আপনাকে কখনই মডেল বা নিয়ামক স্পর্শ করতে হবে না।

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


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

0

আপনি একটি পরিষেবা স্তর প্রবর্তন করবেন না কেন?

তারপরে আপনার নিয়ামক হাতা এবং আরও পঠনযোগ্য হবে, তারপরে আপনার সমস্ত কন্ট্রোলার ফাংশন বিশুদ্ধ ক্রিয়া হবে।

আপনি পরিষেবা স্তর মধ্যে আপনার প্রয়োজন হিসাবে ব্যবসায়িক যুক্তি পচন করতে পারেন। কোড পুনঃব্যবহারযোগ্যতা আরও ভাল এবং মডেল এবং সংগ্রহস্থলগুলিতে কোনও প্রভাব নেই।

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