مدل‌ها، نماها، مدل‌ها؟ این مفاهیم چیست و چگونه می توانند به شما در طراحی نرم افزار کمک کنند؟
برنامه های کاربردی مدرن به چنین ویژگی های متنوعی نیاز دارند که روند توسعه آنها از نظر اندازه و پیچیدگی افزایش یافته است. برای کمک، می توانید از یک الگوی طراحی معماری استفاده کنید. آنها از ساخت برنامه‌هایی پشتیبانی می‌کنند که آزمایش و نگهداری آنها آسان است.
سه الگوی طراحی معروف MVC، MVP و MVVM هستند. MVC مخفف model، view و controller است، در حالی که MVP مخفف model، view و presenter و MVVM مخفف model، view و view مدل است.
الگوهای معماری و طراحی
الگوی معماری
یک الگوی معماری برخی از اجزای حیاتی معماری نرم افزار را روشن و تعریف می کند. حتی اگر یک الگوی معماری تصویری از یک سیستم را منتقل می کند، یک معماری نیست. در واقع، این یک راه حل کلی و قابل استفاده مجدد برای یک مشکل رایج در معماری نرم افزار در یک زمینه خاص است.
الگوی طراحی
یک الگوی طراحی یک بهترین روش رسمی است که می توانید برای حل مشکلات رایج هنگام طراحی یک برنامه یا سیستم استفاده کنید.
تفاوت بین الگوی معماری و طراحی
بیایید با اصطلاح رایج – الگو شروع کنیم. در نرم افزار، یک الگو یک ویژگی تکرارشونده است که به شما امکان می دهد یک ساختار عظیم و پیچیده را به اجزای کوچکتر و ساده تر تقسیم کنید. می توانید از این الگو برای ایجاد یک راه حل کلی برای دسته ای از مشکلات استفاده کنید.
در هر سطح از توسعه نرم افزار، از ابزارهای مختلفی استفاده خواهید کرد. در سطوح کوچکتر، این ابزارها الگوهای طراحی هستند. الگوهای معماری در سطوح بزرگتر و پارادایم های برنامه نویسی در سطح اجرا وجود دارند.
چرا به الگوهای طراحی معماری نیاز داریم؟
در طول توسعه نرم افزار، می توانید از الگوهای طراحی معماری برای حل مشکلات رایج استفاده کنید. معماری خوب همچنین می تواند به شما کمک کند:
- وظایف پیچیده را به کارهای ساده تر تقسیم کنید.
- اشکالات را کاهش دهید.
- کد قابل آزمایش و نگهداری را تولید کنید.
اما بدون الگوی معماری، ممکن است در حفظ منطق تجاری برنامه خود با مشکلاتی مواجه شوید.
Model، View، ViewModel، Controller و Presenter
قبل از اینکه به هر الگو نگاه کنید، در اینجا اصطلاحاتی که آنها را تشکیل می دهند آورده شده است:
- مدل داده ها را ذخیره می کند و مستقیماً با پایگاه داده ارتباط برقرار می کند. مدل بخشی است که داده ها و منطق برنامه شما را نشان می دهد. قوانین تجاری را که مدیریت، اصلاح یا پردازش داده ها را مدیریت می کند، تعریف می کند.
- View داده های مدل را نمایش می دهد و مسئول نمایش داده ها در رابط کاربری است.
- ViewModel مختص الگوی MVVM است. این یک انتزاع از لایه view است و همچنین به عنوان یک پوشش برای داده های مدل عمل می کند.
- کنترلر مؤلفه ای است که نمای و مدل را یکپارچه می کند.
- Presenter کامپوننتی است که فقط در مدل MVP وجود دارد. ارائه دهنده ورودی را از کامپوننت view دریافت می کند و داده ها را با کمک مدل پردازش می کند.
الگوهای MVC، MVP و MVVM
الگوی Model-View-Controller
الگوی معماری MVC اولین مورد بود و امروزه در زمینه برنامه های کاربردی وب رایج است. در دهه 1970 معرفی شد. این الگو به شما امکان می دهد تا یک برنامه کاربردی پیرامون جداسازی نگرانی ها (SoC) بسازید. تلاشی را که برای آزمایش، نگهداری و توسعه اپلیکیشن خود نیاز دارید، آسان می کند.
در الگوی MVC، مدل هیچ درکی از نمای یا کنترلر ندارد. هر زمان که در نمای و کنترلر تغییری ایجاد شود، ناظر مدل یک هشدار دریافت می کند. کنترلر به فرآیند مسیریابی کمک می کند تا مدل را به نمای مربوطه متصل کند.
برخی از مزایای الگوی MVC عبارتند از:
- جداسازی نگرانی ها (متمرکزتر).
- تست و مدیریت کد را آسان تر می کند.
- جداسازی لایه های برنامه را ترویج می کند.
- سازماندهی بهتر کد و قابلیت استفاده مجدد.
در اینجا نحوه کار MVC آمده است:
با توجه به SoC، MVC می تواند اندازه کد را کاهش دهد و کد خوبی ایجاد کند که تمیز و قابل مدیریت باشد.
الگوی Model-View-Presenter
الگوی MVP با MVC دو جزء مشترک دارد: مدل و view. این کنترلر را با ارائه دهنده جایگزین می کند. ارائه دهنده – همانطور که از نامش پیداست – برای ارائه چیزی استفاده می شود. این به شما امکان می دهد تا به راحتی نمای را مسخره کنید.
در MVP، ارائه دهنده عملکرد “مرد میانی” را دارد زیرا تمام منطق ارائه به آن فشار داده می شود. نمایش و ارائه کننده در MVP نیز مستقل از یکدیگر هستند و از طریق یک رابط تعامل دارند.
در اینجا تصویری از نحوه عملکرد الگوی MVP آورده شده است:
ارائه دهنده ورودی از کاربر از طریق View دریافت می کند. سپس اقدامات کاربر را با کمک مدل پردازش می کند و نتایج را به نمایش ارسال می کند. ارائه دهنده از طریق واسط ها با دیدگاه ارتباط برقرار می کند.
Model-View-ViewModel Pattern
MVVM تکامل مدرن MVC است. هدف اصلی MVVM ایجاد یک جدایی واضح بین منطق دامنه و لایه ارائه است. MVVM از اتصال دو طرفه داده بین view و viewmodel پشتیبانی می کند.
الگوی MVVM به شما امکان می دهد نمای و مدل کد خود را از هم جدا کنید. این بدان معناست که وقتی مدل تغییر می‌کند، نما نیازی به این کار نیست و بالعکس. با استفاده از یک viewmodel، می توانید تست واحد انجام دهید و رفتار منطقی خود را بدون درگیر کردن دیدگاه خود آزمایش کنید.
در اینجا تصویری از نحوه کار MVVM آورده شده است:
زمان استفاده از MVC، MVP و MVVM
اکنون که در مورد هر الگوی یاد گرفتید، زمان استفاده از آنها را بیابید.
زمان استفاده از MVC
MVC به سادگی پیاده سازی Separation of Concerns است. اگر برنامه شما نیاز به جداسازی داده ها (مدل)، خرد شدن داده ها (کنترل کننده) و ارائه داده ها (نما) داشته باشد، MVC به خوبی کار خواهد کرد. MVC همچنین در برنامه‌هایی که منبع داده و/یا ارائه داده می‌توانند در هر زمان تغییر کنند، به خوبی عمل می‌کند.
زمان استفاده از MVP
زمانی می توانید از MVP استفاده کنید که برنامه شما دارای جریان دو طرفه باشد. اگر تعاملات کاربر نیاز به درخواست چیزی از مدل داشته باشد و نتیجه این درخواست بلافاصله رابط کاربری را تغییر دهد، MVP را در نظر بگیرید.
زمان استفاده از MVVM
زمانی که می خواهید از MVVM استفاده کنید:
- شما باید یک پروژه را با یک طراح به اشتراک بگذارید و کار طراحی و توسعه می تواند به طور مستقل اتفاق بیفتد.
- برای راه حل های خود به تست واحد نیاز دارید.
- شما باید اجزای قابل استفاده مجدد، هم در داخل و هم در پروژه های سازمان خود داشته باشید.
- شما برای تغییر نماهای خود بدون نیاز به تغییر منطق دیگر در پایه کد، انعطاف بیشتری می خواهید.
کدام الگو را باید انتخاب کنید؟
دلیل اصلی استفاده از الگوی طراحی کاهش پیچیدگی است. شما می توانید این کار را با کاهش پیچیدگی کلی یا با جایگزین کردن پیچیدگی ناآشنا با چیز آشنا انجام دهید. اگر یک الگوی طراحی نمی تواند پیچیدگی را به یکی از این دو روش کاهش دهد، از هیچ یک از آن استفاده نکنید. هیچ ارزشی اضافه نخواهد کرد.
اگر واقعا مطمئن هستید که باید از یک الگوی طراحی استفاده کنید، سعی کنید یک چک لیست تهیه کنید. آن را بر اساس موقعیت هایی که در اینجا دیده اید، قرار دهید و بهترین مناسب را برای پروژه خود انتخاب کنید.