کلمه Model در مباحث مختلف طراحی چه معنی ایی می دهد

کلمه Model در مباحث مختلف چه معنی ایی می دهد؟ در اینجا به بررسی کلمه مدل در MVC، ViewModel، Domain Model و Persistence Model خواهیم پرداخت.1. در الگوی MVC، حرف M مخفف Model می باشد. در این الگو Model، به معنی هر چیزی اعم از منطق و بیزینس نرم افزار، کار با پایگاه داده، سرویس ها و .... می باشد. هر تلاشی برای تغییر حالت سیستم و داده ها، هر تلاشی برای واکشی داده ها بیانگر کلمه Model می باشد.2. در الگوی ViewModel، معتقدیم که هر چیزی که می خواهیم به کاربر نمایش دهیم، یک View می باشد و هر View محتوی داده هایی (مدل) برای نمایش به کاربر می باشد. در این الگو، برای پاس دادن داده ها به View از کلاسی به نام ViewModel استفاده می کنیم. کلاس های ViewModel رفتار و متدی ندارند که در وضعیت سیستم تغییری ایجاد کنند. این کلاس ها، متناسب با View طراحی می شوند و فقط حاوی داده هستند ( مثلا در سی شارپ، ViewModel ها عمدتا فقط از Property تشکیل شده اند). View با خواندن داده ها از این کلاس به راحتی می تواند داده ها را به کاربر نمایش دهد. پس در اینجا برخلاف MVC که کلمه مدل معنی گسترده و نامشخصی داشت، کلمه Model فقط بیانگر نوعی از کلاس ها می باشد که داده های View را فراهم می کنند. توصیه می شود، برای هر View، یک ViewModel متناظر داشته باشیم. 3. عنوان Domain Model از آن دست کلماتی است که توسط فلسفه Domain Driven Design یا DDD وارد دایره لغات ما شده است. به طور خیلی خلاصه، در این فلسفه، تمرکز بر روی مسائل و مشکلات دنیای واقعی می باشد و بر روی پروژه هایی با ابعاد بزرگ و پیچیده به کار خواهد رفت، مانند راه اندازی اتوماسیون سازمانی بزرگ با بخش های مختلف کاری و یا طراحی و پیاده نرم افزاری که قرار است بیزینس پیچیده، گسترده و چند بعدی داشته باشد.در DDD، کلمه Domain به معنی مسئله و راه حل های مربوطه در دنیای واقعی می باشد. مثلا می گوییم Domain ما مرتبط با مسائل مالی و بانکی است.برای انتقال مسئله به قالب نرم افزار، نیاز هست تا مدل سازی انجام دهیم، که در اینجا به مجموعه مدل هایمان، Domain Model گفته می شود. Domain Model ها، به کلاس هایی گفته می شود که توامان هم دارای "داده و حالت" می باشند و هم با داشتن "متد"، دارای "رفتار" می باشند. این بر خلاف ViewModel ها است که صرفا دارای "داده" بودند.رفتارهای این کلاس ها، قوانین و محدودیت ها، فرایند ها و رخدادهای بیزینس را اعمال می کنند و انجام می دهند. مثلا در Domain ِ بانکی، کلاس Customer یک Domain Model است، که می تواند دارای متدهایی برای برداشت از حساب، باز کردن حساب باشد و یا دارای متدی برای اعلام سرقت کارت بانکی اش باشد. در داخل این متد ها، البته می توانیم به لایه های سرویس مراجعه کنیم و امور را در انجام دهیم. نزدیکی Domain Model به Domain و دنیای واقعی باید به حدی باشد که در نام گذاری تمام اجزای کلاس از کلماتی استفاده می کنیم، که متخصصین واقعی آن حوزه از آن استفاده می کنند و نه کلماتی که معمولا برنامه نویس ها به ذهن شان خطور می کند! وظیفه Domain Model ها، مدل سازی مسائل دنیای بیرونی می باشد. کلاس هایی که معادلی در دنیای خارج ندارند و به دلایل دیگری ساخته شده اند، در حوزه Domain Model قرار نمی گیرند.همچنین هر مدل در اینجا، لازم نیست در پایگاه داده ذخیره شود و یا معادلی در جدول ها داشته باشد. در واقع در حالت ایده آلِ DDD (که همیشه عملی نیست) باید این لایه به طور کلی هیچ وابستگی ایی به ORM و زیرساخت نداشته باشد. نکته بعدی آن است که Domain Model، بخش بسیار مهم و عمده ای از لایه بیزینس می باشد. به همین دلیل برای طراحی Domain Model صحیح باید تعامل بسیار خوبی بین متخصصین بیزینس و تیم تحلیل نرم افزاری وجود داشته باشد. 4. در عبارت Persistence Model، منطور ما از مدل مجموعه کلاس هایی است که همانند ViewModel فقط دارای داده می باشند و هیچ رفتاری ندارند. هدف غایی این کلاس ها آن است که داده هایشان را در پایگاه داده ذخیره کنیم. مثلا در ORM ها (مانند Entity Framework) ما با این دست از کلاس ها کار می کنیم. هر کلاسی در اینجا، معادل با یک جدول در پایگاه داده می باشد. ممکن است یک مدل در Domain Model از تشکیل و قرارگرفتن چند مدل در لایه Persistence تشکیل شده باشد. مثلا در Domain Model کلاس Customer می تواند همزمان شامل اطلاعات حساس مالی و اطلاعات شخصی باشد. ولی در Persistence Model، ما به دلایلی این دو نوع داده را در جداول جدایی ذخیره خواهیم کرد.