এমভিসিতে এম কোথায়?


14

আমি আমার অ্যাপ্লিকেশনটিকে এমভিসিতে রিফ্যাক্টর করার চেষ্টা করছি, তবে আমি এম অংশে আছি।

একটি ডাটাবেস-ব্যাক অ্যাপ্লিকেশনটিতে, মডেলটি অ্যাপ কোডটিতে প্রয়োগ করা হয়েছে, তাই না?

তবে, ডাটাবেসে কী আছে - তাও কি মডেল নয়?

(আমি একটি সাধারণ অবজেক্ট স্টোর হিসাবে ডাটাবেস ব্যবহার করছি না - ডিবিতে ডেটা একটি এন্টারপ্রাইজ সম্পদ)।


I'm not using the database as a simple object store। আমি অনুমান করছি যে সঞ্চিত পদ্ধতি আকারে ডাটাবেসে কিছু ব্যবসায়িক যুক্তি। তত্ত্বের ক্ষেত্রে যা এমভিসির বিপরীতে যায় তবে বাস্তবে এটি কোনও বিষয় নয়।
ইয়ানিস

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

3
I want the data in the DB to have a life and meaning beyond the application.কি?
ইয়ানিস

2
@ ইয়ানিসরিজোজ - আমি অবশ্যই এই বিবৃতিটি পুনরায় সংশোধন করতে সহায়তা করব। ডেটা একটি এন্টারপ্রাইজ সম্পদ, তাই না? এটা তোলে অ্যাপ্লিকেশন অন্তর্গত নয় - তাই অ্যাপ্লিকেশন কিছু পাগল denormalized মডেল খুব সহজ করে তোলে যে তৈরি করার অনুমতি দেওয়া হয় না অ্যাপের জন্য যে, যদি খুব কঠিন অন্যান্য অ্যাপ্লিকেশন থেকে ডেটা পুনঃব্যবহার করে তোলে। কোনও পরামর্শ?

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

উত্তর:


46

হ্যাঁ, কোড এবং ডাটাবেসের দুটি মডেলই "মডেল"।

মডেলটির সাথে আপনার অ্যাপ্লিকেশন "আইএস" কী করতে হবে, এবং নিয়ামক এটি "কী" করে। ডাটাবেসের সরাসরি অধ্যবসায়ের সাথে মোকাবেলা করা কোনও কোডকে মডেল হিসাবে বিবেচনা করা হয়।

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


15
সুতরাং সি এবং ভি এর দৃষ্টিকোণ থেকে, একটি ডাটাবেস আছে কি এম এর একটি বাস্তবায়ন বিশদ?

স্পষ্টভাবে. সুন্দরভাবে শব্দযুক্ত।
হার্বি

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

5
"এমভিসি ওভারথিংক করবেন না" এর জন্য +1
জাভিয়ের

2
"আপনার ব্যবসায়ের যুক্তিটি ডেটাবেস এবং ইউআই এর বাইরে রাখুন" - এটি
ডেভিড মুরডোক

17

ট্রাইগভে রেইনসকাগ ১৯8৮ সালে এমভিসি প্যাটার্নটি বর্ণনা করে প্রাথমিক কাগজপত্র লিখেছিলেন। তাঁর বর্ণনার মডেলটি হ'ল বিশ্ব মডেল, ঘটনা এবং ধারণার প্রতিনিধিত্বকারী অবজেক্ট মডেল। আপনার ডাটাবেস-সমর্থিত অ্যাপ্লিকেশনটির দৃশ্যে, মডেলটি হ'ল আপনার ডেটা প্রজেকশন। এটিকে সহজভাবে বলতে গেলে, মডেল হল ক্লাসগুলি এবং তাদের সম্পর্ক যা আপনার অ্যাপ্লিকেশনটির সাথে সম্পর্কিত।

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


+1: আমার এই উত্তরটি সবচেয়ে ভাল লেগেছে। The model is a projection of your data.ডাটাবেসটি অ্যাক্সেস এবং ইনডেক্সিংয়ের জন্য সবচেয়ে কার্যকরী উপায়ে ডেটা সঞ্চয় করতে ডিজাইন করা হয়েছে। পরিবর্তে ব্যবসায়িক ডোমেনকে ঘিরে মডেলটি ডিজাইন করা উচিত।
জোয়েল ইথারটন 14

পার্স করার জন্য আমাকে এক সেকেন্ড নিয়েছে the Domain Model (what's mapping to your database)। চমৎকার উত্তর!

2
+1 এটি এমভিসি রূপান্তরিত বিভিন্ন স্বাদের একটি দুর্দান্ত বর্ণনা।
রায়ান হেইস

ধন্যবাদ বন্ধুরা. আমার বইটি লেখার সময় আমি এই জিনিসগুলিতে গভীরভাবে ডুব দিচ্ছি। খুশী তা বোঝায়!
মাইকেল ব্রাউন

3
  1. এমভিসির জন্য আপনার কোনও ডাটাবেস লাগবে না। যদি আপনার মডেলটি ডাটাবেসের সাথে কথা বলে থাকে তবে দুর্দান্ত। এটি কোনও ফ্ল্যাট ফাইলের কাছেও স্থির থাকতে পারে বা নিজেকে স্থির রাখতে পারে না।

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

  3. দৃশ্যটি যুক্তিযুক্ত বোকা হওয়া উচিত, হয় না কোনও যুক্তি নেই, বা কেবল সাধারণ ডেটা বাইন্ডিং ব্যবহার করে ( মার্টিন ফাউলারের সাইটে প্যাসিভ ভিউ এবং তদারকির নিয়ন্ত্রক নিদর্শনগুলি দেখুন )। যখন ব্যবহারকারী স্টাফ করেন তখন দৃশ্যগুলি ইভেন্টগুলি উত্থাপন করে, যেমন একটি বোতামে ক্লিক করা।

  4. কন্ট্রোলার ইভেন্টগুলি পরিচালনা করার জন্য (ব্যবহারকারী ক্লিক করুন যখন কিছু সংরক্ষণ করুন বোতাম সংরক্ষণ করুন), এবং মডেল বৈশিষ্ট্য নির্ধারণের জন্য, এবং মডেলকে লোড করতে এবং নিজেকে সংরক্ষণ করতে বলার জন্য (যদি জেদ ব্যবহার করে) দায়বদ্ধ। নিয়ামকটি মডেলের ডেটাতে গণনা করা উচিত নয়। তবে কন্ট্রোলারে আপনি ভিউর পক্ষে কিছু গণনা করতে পারেন যেমন "যদি মডেল.প্রফিট () <0 তারপর উইজেট কোডল = 'লাল'"

  5. মডেলগুলি পরিবর্তন না করে এবং মডেলগুলির কার্যকারিতা হারিয়ে না ফেলে আপনার অ্যাপ্লিকেশনটির একটি কমান্ড লাইন সংস্করণে স্যুইচ করতে সক্ষম হওয়া উচিত।

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


ঠিক! এটা খুব পরিষ্কার।

2

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


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

(উপরে যখন কেবল ডিবিতে ডেটা অন্য কোনও অ্যাপ্লিকেশনের সাথে ভাগ করা হয় না তখনই পরিস্থিতিগুলির জন্য ধারণ করা হয়)
হার্বি

আমি আমার মন্তব্যে দুর্বল শব্দ-নির্বাচনের জন্য ক্ষমা চাইছি - আমি যা বলতে চাইছিলাম তা হ'ল এমভিসির সাথে ডেটাবেজে কী আছে তা আমি নিশ্চিত নই । ডাটাবেস কি এমভিসির বাইরে? এটি কি মডেলের অংশ? এটি ভি বা সি এর অংশ (সম্ভবত না, তবে আপনি পয়েন্টটি পান)।

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

চরম ক্ষেত্রে, যখন ব্যবসা লজিক ডিবি নিজেই চলে এলে, আপনি খুব পাতলা মডেল বেশিরভাগই ডিবি থেকে relays এর, অথবা এমনকি বলে যে ডিবি থাকতে পারে হয় আপনার মডেল (কিন্তু তারপর, এটা থাকা উচিত সব লজিক)।
Herby

2

খুব সরল ও আদর্শবাদী দৃষ্টিভঙ্গি গ্রহণ করা।

মডেলটিকে সাধারণত ডোমেনের মডেল হিসাবে দেখা হয় (মোটামুটি, ব্যবসা), তথ্যের মডেল হিসাবে নয়। এগুলি দেখতে অনুরূপ হতে পারে তবে তারা একে অপরের সাথে পুরোপুরি আবদ্ধ নয়।

ভিউটি অ্যাপ্লিকেশনের সম্মুখ প্রান্তের মডেল হওয়া উচিত এবং নিয়ামকটি এক ভিউ থেকে অন্য ভিউতে প্রবাহের মডেল হওয়া উচিত।

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


1

আমার বোঝার জন্য, এমভিসি হ'ল আপনার ক্লায়েন্ট অ্যাপ্লিকেশনটির স্থাপত্য বিন্যাসের বিবরণ মাত্র। উইকিপিডিয়ায় এখানে চিত্রটি এটি দেখায়:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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


1
But then, what is in the database -- is that not also the model?

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

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

নিয়ামকের সাথে একই যায়। এমভিসি নিয়ামককে দুটি স্তরের মধ্যবর্তী ব্যক্তি হিসাবে সংজ্ঞায়িত করে। এমভিসিতে কোনও "ব্যবসায় স্তর" সংজ্ঞায়িত হয়নি। বরং আপনি নিজের যোগ করুন। এমভিসি বেশিরভাগ অ্যাপ্লিকেশন তৈরি করার জন্য প্রয়োজনীয় সমস্ত স্তরকে আবদ্ধ করে না। এটি মূল কাঠামোর জন্য একটি সাধারণ নির্দেশিকা guid

এই বিভাজনগুলি নিয়ন্ত্রণের বিপরীতটিকে কাজ করতে দেয় function


একটি দুর্দান্ত এবং খুব তথ্যপূর্ণ উত্তরের জন্য +1; যদিও, আমি পরামর্শ দিই যে চূড়ান্ত বাক্যটি বর্ণনার উপযুক্ত। আইওসি অগত্যা বিস্তৃতভাবে পরিচিত এবং বোঝে না, সুতরাং এটি একটি বিভ্রান্তির একটি সামান্য বিট যোগ করতে পারে। এর দ্বারা আপনি কী বোঝাতে চেয়েছেন তার সত্যিকারের দরকারী ব্যাখ্যা সম্ভবত একটি বুদ্ধিমান এসই উত্তরের সুযোগের বাইরে নয়, তবে এটি আমার দিকে ঝাঁপিয়ে পড়েছিল।
অ্যাডাম ক্রসল্যান্ড

তবে, আপনি যদি সঞ্চিত পদ্ধতিতে আপনার ব্যবসায়িক যুক্তি রাখেন, তবে হ্যাঁ, ডাটাবেসটি মডেলটিকে পরিবেষ্টন করে। (ব্যক্তিগতভাবে, আমি সেই পদ্ধতির সুপারিশ করব না))
রায় টিঙ্কার

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

1

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

আরও দেখুন: http://martinfowler.com/bliki/AnemicDomainModel.html


0

এটি আসলে খুব সহজ, "মডেল" ডেটা ইন্টারফেসের বিমূর্ততা উপস্থাপন করে। এই কারণে:

  • ডেটাবেসগুলিকে মডেলের অংশ হিসাবে বিবেচনা করা হয় তবে এটি নিজেই মডেল নয়
  • মডেলটির ডেটা ডাটাবেস, ফাইল, ওয়েব-পরিষেবাগুলি বা এমনকি উপহাস করা হতে পারে।
  • এমভিসি, এইচএমভিসি বা অনুরূপ ফ্রেমওয়ার্কগুলিতে মডেল ক্লাসগুলিতে ক্যোয়ারী সংরক্ষণ করা উচিত ( "ফ্যাট মডেল, চর্মসার নিয়ামক" নীতি দেখুন [ 1 ] [ 2 ] [ 3 ])

এবং যদি আমি সঠিক - তাই কেন কেউ যখন এমভিসি প্রসঙ্গে বাইরের মডেলগুলি উল্লেখ করে, যে কেউ সম্ভবত ডেটাটির কাঠামোকে বোঝায় (অর্থাত্ স্কিমা )।


0

আমি মনে করি এম এর কিছু যুক্তি রয়েছে এবং ডিবিতে ডেটা সঞ্চয় করে। কোন মডিউলটি কার্যকর করা হবে এবং এই মডিউলটি ডিবিতে লজিকস এবং স্টোর ডেটা চালায় এবং তারপরে এই মডিউলটির মান ফিরে আসে to


0

এমভিসিতে এম (ওডেল) একক জায়গায় ব্যবসায় / ডোমেনের মডেলটি ক্যাপচার করবে ।

যে আদর্শভাবে অন্তর্ভুক্ত করা উচিত ব্যবসার নীতি ডোমেনের সেইসাথে এটা কাঠামো।

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

ডাটাবেস স্তরটি নির্দিষ্ট সময়ে নির্দিষ্ট সময়ে মডেলটির অবস্থার সাথে দৃ only়তার সাথে কেবল ডিল করে (বা বরং কেবলমাত্র ডিল করা উচিত)।

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


0

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

মডেল এবং সঞ্চিত ডেটাগুলির মধ্যে মিথস্ক্রিয়া হয় একটি পৃথক ডেটা স্তরে বা সরাসরি মডেলে ঘটতে পারে, যা কোনও ওআরএম (অবজেক্ট রিলেশনাল ম্যাপার) ব্যবহার করার সময় ঘটে। অন্য কথায় হয় হয় মডেলটি সরাসরি ডাটাবেসের সাথে সংযুক্ত হয় বা এটি তার ডেটাটিকে কিছু অন্যান্য "ডেটা অ্যাক্সেস" অবজেক্টের সাথে পাস করে যা ডাটাবেসের সাথে সংযুক্ত থাকে।

একটি ওআরএম (অবজেক্ট রিলেশন ম্যাপার) ডাটাবেস টেবিলের ক্ষেত্রগুলিকে আপনার মডেল অবজেক্টের বৈশিষ্ট্যগুলিতে মানচিত্র তৈরি করে এবং সেটটার সরবরাহ করে। এই ক্ষেত্রে কোনও আলাদা ডেটা স্তর নেই এবং মডেলটি তার ডেটা ধরে রাখার জন্য সরাসরি দায়বদ্ধ directly

এখানে ActiveRecordএকটি জনপ্রিয় ওআরএম ব্যবহার করে একটি রুবির উদাহরণ দেওয়া হল :

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Pricehousesটেবিলের এমন একটি ক্ষেত্র যা স্বয়ংক্রিয়ভাবে সনাক্ত করা যায় ActiveRecordযা বস্তুটিতে একটি গিটার এবং সেটটার যুক্ত করে। কখনsave মূল বৈশিষ্ট্যের মান বলা হয় তখন ডাটাবেসে স্থির থাকে।

আমার দৃষ্টিকোণ থেকে ডেটা লেয়ার থাকার প্রবাদটি হ'ল আপনি এমন একটি পয়েন্ট পাবেন যাতে আপনি মডেলটিতে পৌঁছানোর আগেই ডেটা ম্যানিপুলেট করতে পারেন, মডেলটির এটি নিয়ে কম উদ্বেগ রয়েছে, এর কম দায়িত্ব রয়েছে। উদাহরণস্বরূপ, আপনাকে বেশ কয়েকটি নয় কোনও সামঞ্জস্যপূর্ণ ডেটা উত্স থেকে ডেটা একত্রিত করার প্রয়োজন হতে পারে, এটি এমন একটি বিষয় যা কোনও ওআরএম সহজেই হ্যান্ডেল করতে পারে না।

মূল কনটি পরিচালনা করার জন্য এটি বিমূর্ততার আরেকটি স্তর, যদি আপনার এটির প্রয়োজন না হয়, বিরক্ত করবেন না, সহজ রাখুন। কম চলন্ত অংশ, ভুল হতে কম।


-1

হ্যাঁ তুমিই ঠিক.

(মডেল ভিউ কন্ট্রোলার)

অ্যাপ্লিকেশন তৈরির জন্য একটি আর্কিটেকচার যা ইউজার ইন্টারফেস (ভিউ) এবং প্রসেসিং (কন্ট্রোলার) থেকে ডেটা (মডেল) পৃথক করে।

অনুশীলনে, এমভিসি ভিউ এবং কন্ট্রোলারগুলি প্রায়শই একটি একক সামগ্রীতে একত্রিত হয় কারণ এগুলি ঘনিষ্ঠভাবে সম্পর্কিত। এমএসডিএন অনুসারে

নিয়ামকটি ব্যবহারকারী থেকে মাউস এবং কীবোর্ড ইনপুটগুলি ব্যাখ্যা করে, এবং মডেলটি এবং / অথবা inform the view to change as appropriate.

এই চিত্রটি পরীক্ষা করুন:

এখানে চিত্র বর্ণনা লিখুন

উদাহরণস্বরূপ, কন্ট্রোলার কোড ডেটার জন্য একটি অনুরোধকে বৈধতা দেয় এবং এটি একটি দর্শনে ফিরে আসে to ভিউ-কন্ট্রোলার অবজেক্টগুলি কেবল একটি মডেলের সাথে আবদ্ধ; যাহোক,a model can have many view-controller objects associated with it.


4
In practice, MVC views and controllers are often combined into a single object because they are closely related.আপনি যদি এটি করেন তবে আপনি এটি ভুল করছেন ...
ইয়ানিস

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

@ ইয়ানিস রিজোস - তিনি এমএস ডকুমেন্টেশনের উদ্ধৃতি দিচ্ছেন। এটি এখানে কিছুটা প্রসঙ্গে নয়, তবে তারা বলছেন যে নন-ওয়েব অ্যাপ্লিকেশনগুলিতে প্রায়শই দেখা / নিয়ন্ত্রকের সংমিশ্রণ থাকে, তবে ওয়েব অ্যাপ্লিকেশনগুলির মধ্যে একটি খুব স্পষ্ট পার্থক্য রয়েছে। আপনি সম্ভবত এমএস তাদের উইন্ডোজ অ্যাপ্লিকেশনগুলির (এমভিভিএম পরিবর্তে) কেবল ওয়েব-অ্যাপ্লিকেশনগুলির জন্য এমভিসিটিকে চাপ দিচ্ছেন না এমন একটি কারণ সম্ভবত। msdn.microsoft.com/en-us/library/ff649643.aspx
P.Brian.Mackey

1
@ পি। ব্রায়ান.ম্যাকি আমার সন্দেহ হয়েছিল এমএস এর পিছনে কিছুটা পিছনে ছিল: পি
ইয়ানিস

@ P.Brian.Mackkey সরবরাহ করা লিঙ্কটি অন্তর্ভুক্ত করার জন্য আমি আপনার উত্তর সম্পাদনা করেছি। বাহ্যিক উত্সগুলি উদ্ধৃত করা পুরোপুরি ঠিক আছে তবে আপনাকে অবশ্যই তাদের লিঙ্কগুলি অন্তর্ভুক্ত করতে হবে। এছাড়াও এমভিভিএম এমভিসির সাথে খুব মিল থাকতে পারে তবে এটি একই ধরণের নয় not এমভিসি ভিউ এবং কন্ট্রোলারগুলিকে কখনও কোনও একক বস্তুর সাথে একত্রিত করা উচিত নয় ...
ইয়ানিস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.