پروژه درس معماری نرم افزار

مقدمه

الگوهای طراحی نرم افزار برای ایجاد برنامه های نرم افزاری مقیاس پذیر، قابل نگهداری و کارآمد ضروری هستند. از محبوب ترین الگوهای طراحی می توان به

MVC(Model View Controller)

MVP(Model View Presenter)

MVVM (Model-View-ViewModel)

اشاره کرد. هر یک از این الگوها مجموعه ای از مزایا و معایب خاص خود را دارند و درک آنها برای تصمیم گیری آگاهانه هنگام طراحی نرم افزار بسیار مهم است. در این مقاله، جزئیات هر یک از این الگوهای طراحی را بررسی خواهیم کرد و مزایا و معایب آنها را بررسی خواهیم کرد. ما آنها را با هم مقایسه خواهیم کرد تا درک جامعی از تفاوت ها و شباهت های آنها ارائه دهیم. در پایان این مقاله، درک روشنی از آنچه که MVC، MVP و MVVM هستند و چگونه می توان از آنها در توسعه نرم افزار استفاده کرد، خواهید داشت.

MVC

با نگاهی به تاریخچه الگوی طراحی MVC درمیابیم که ابتدا توسط Trygve Reenskaug در سال 1970 پیشنهاد شد به گفته وی : هدف اصلی الگوی طراحی MVC این است که شکاف بین مدل ذهنی کاربر انسانی و مدل دیجیتالی موجود در رایانه را پر نماید.

در سال 1988 این الگوی طراحی توسط Krasner و Pope در مقاله ای که ارائه دادند مفصل توضیح داده شد مقاله ای به نام “A cookbook for using the model-view-controller user interface paradigm Smalltalk-80 ” تاکید انان در مقالشان این بود که ساخت برنامه با ذهنیت ماژولار دارای مزایای بسیاری است. جداکردن فانکشن ها از یکدیگر تا حد امکان این امکان را میسر میسازد که که برنامه سازان درک خوبی از هر یونیت داشته باشند و تغییر هر بخش برایسان بسیار راحت تر و سریع تر میشود.

الگوی طراحی MVC خلاصه شده Model برای M , view برای V و Controller برای C میباشد. زمانی که از MVCاستفاده میشود بطور خلاصه درخواست ها به یک کنترلر هدایت میشود که مسئول کار کردن با یک مدل برای انجام دادن اقدامات لازم و یا حتی بازیابی داده است . کنترل سپس View را برای نمایش انتخاب میکند و مدل را در اختیار ان قرار میدهد . در نهایت هم view صفحه نهایی را بر اساس داده های مدل انتخاب میکند. در ادامه تک تک این موارد را بصورت کامل توضیح میدهیم و بررسی مینمایم.

Model

بخش مدل با تمامی منطق مربوط به داده که کاربر با ان کار میکند مطابقت دارد مثل دیتابیس Validation و غیره. از خوبی های بخش مدل این است که ساختار پیچیده کد که برنامه نویس با ان سروکار دارد میکاهد پس در نتیجه روند توسعه ساده تر میشود.

لایه مدل مسئول منطق داده های برنامه و ذخیره و بازیابی داده ها از داده های بک اند است.باید تمامی جنبه های داده را در خود حفظ نماید و از یپارچگی و دسترسی به ان ها اطمینان حاصل کند.باری مثال یک ابجکت مشتری اطلاعات مشتری ما را از پایگاه داده بازیابی میکند سپس ان را دستکاری کرده و داده های آن را بروزرسانی میکند و یا از ان برای ارائه داده ها استفاده میکند.

لایه مدل مسئول منطق تجاری (business logic) را بر عهده دارد و معمولا یک مدل با در نظر گرفتن انتزاع داده ها اعتبار سنجی و احراز هویت ساخته میشود.

بطور خلاصه مدل با پایگاه داده ارتباط دارد و میتواند اطلاعات را بازیابی و یا اضافه نماید و به درخواست های کنترلر پاسخ میدهد.

View

بخش view همانگونه که از اسمش مشخص است مسئولیت رابطه گرافیکی است. در این بخش فناوری های مربوط به فرانت اند قرار میگیرد که در حالت کلی شامل : HTML,CSS,Javascript است که میتواند شامل فریم ورک های مربوطه هم باشد مثل فرم های معروف bootstrap باری Css و یا React,Vuejs برای جاوااسکریپت. تمامی المان های قابل مشاهد در این بخش قرار میگیرند شامل تصاویر فرم ها کلمات و غیره .با جداسازی این موارد از منطق برنامه نویسی هرگونه تغییر در طرح گرافیگی بطورچمگیری راحت تر میشود و این تغییرات موجب روز خطاهای ناخواسته در حین کار نیز نمیشوند زیرا در بخش جدایی قرار دارند .

View نباید منطق یا logic برانامه را داشته باشد به این خاطر که طراح ما بتواند به سادگی با ان کار کند.

پس به طور خلاصه ویو قالب صفحه ما است که تمام اجزای گرافیکی را در خود جای داده است

controller

شامل منطق برنامه ما سات که ارتباط بین view و model را نیز برقرار میکند. یک کنترلر در خواست ها میگیرد و داده ها را برای پاسخ اماده میسازد به این صورت که با مدل در ارتباط است و داده ها را از مدل دریافت میکند و بخش ویو را تولید میکند. سیستم کنترل کننده معمولا RESTfull است و از فرمت json نیز استفاده میکند.

کنترل نیازی ندارد که نگران منطق برنامه باشد فقط لازم است که به مدل بگوید که چه کاری باید انجام دهد.

بطور خلاصه کنترلر تمام منطق های تجاری و درخواست های دریافتی را کنترل میکند مثل زمانی که کاربر دکمه ای را فشار میدهد سپس داده ها را با استفاده از مدل دستکاری میکند و با ویو تعامل میکند تا خروجی نهایی را ارائه کند.

مزایا

MVC با جدا کردن اجزای مدل ویو و کنترلر مدیریت و کنترل کد را تسهیل میبخشد .

قابلیت استفتده مجدد از کد را ایجاد میکند به این صورت که اجزا مجددا در بخش های مختلف برنامه مورد استفاده قرار گیرند که باعث کاهش تکرار و بهبود کارایی میشود

استفاده از MVC باعث میشود نوشتن unit test ها اسان تر شود در نتیجه کیفیت کد بیشتر میشود

در بخش مقیاس پذیری نیز تغییر دادن کد را رحت تر میکند و افزودن ویژگی جدید یا اصلاح یک بخش تاثیری بر سایر بخش ها ندارد

در نتیجه استفاده از mvc در چهار بخش Reusibility, Testability, Scalability تاثیر مثبت دارد

معایب

پیاده سازی ساختار معماری MVC دارای پیچیدگی است بخصوص برای افراد تازه کار و یا توسعه دهندگانی که با ان اشنایی نداردند که نیاز دارند به درک خوبی از نحوه تعامل بخش های مختلف باهم داشته باشند

توسعه دهنگاه نیاز دارند تا زمانی را برای یادگیری و تسلط بر این الگو قرار دهند که این باعث کندی در کار میشود و سرعت توسعه را پایین می آورد

در آخر میتواند باعث سربار اصافه شود زیرا لایه های زیادی برای پردازش درخواست های کاربر وجود دارد.

MVP

در سال 1990 الگوی MVP در پروژهTaligent که توسط برخی از شرکت ها مانند IBM، APPLE، HP بر اساس زبان C++ آغاز شده بود، ظاهر شد. پس از مدتی مایک پاتل این الگو را برای جاوا تکامل داد. هنگامی که پروژه Taligent در سال 1997 شکست خورد، اندی باور و بلر مگالشان رابط کاربری اسمال تاک را با استفاده از این الگو تکمیل کردند. در سال 2006 مایکروسافت این الگو را برای برنامه نویسی رابط کاربری در سیستم های مبتنی بر Net توسعه داد. MVP یک الگوی طراحی رابط کاربری است که لایه مدل را از رابط کاربری خارج می کند و اشکال زدایی را بسیار آسان می کند. این الگو از این سه لایه model و View و Presenter ساخته شده است

الگوی MVP از الگوی معروف MVC (Model-View-Controller) تکامل یافته است. در این مدل لایه presenter تغییر بافته است اما در ایده اصلی، آنها مکان یکسانی دارند: مدل لایه داده است که مسئول دسترسی به داده است. View لایه نمایش است که وظیفه نمایش داده ها را بر عهده دارد. کنترل کننده/ارائه کننده لایه منطقی است که مسئول پردازش منطقی است. در این مدل لایه presenter تغییر بافته است.

model

دقیقا همانند الگوی طراحی MVC بخش model در MVP نیز مسئولیت ذخیره داده را دارد همچنین مسئولیت مدیریت منصق های دامین و ارتباطات با پایگاه داده را دارا میباشد .

View

بخش view در الگوی طراحی MVP همانند مورد قبلی که در MVC توضیح داده شد با رابط کاربری کار دارد که در آن قالب صفحه را قرار میدهیم به این صورت که مثلا تمامی دکمه ها فرم ها رنگ ها و نوشته های داخل صفحه باید داخل بخش view قرار بگیرند که عمدتا توسط HTML,CSS,Javascript توسط توسعه دهندگا نوشته میشود

Presenter

تنها بخشی که باعث ایجاد تفاوت بین MVC و MVP میشود بخش Presenter است .

به عنوان یک واسطه بین مدل و ویو عمل میکند.مسئول مدیریت ورودی کاربر, به روزرسانی مدل و بروزرسانی ویو بر این اساس میباشد

در بخش مدیریت ورودی کاربر ارائه دهنده ورودی کاربر را از ویو دریافت میکند و آن را پردازش میکند سپس با مدل تعامل میکند تا هرگونه عملیاتی منطقی تجاری لازم را بر اساس ورودی کاربر انجام دهد.پس از پردازش ورودی کاربر و تعامل با مدل presenter ویو را بروزرسانی میکند تا هرگونه تغییر در داده و یا وضعیت را منعکس نماید این میتواند شامل بروزرسانی اجزای رابط کاربری ,نمایش پیام هایخطا یا حتی فعالی کردن انیمیشن ها باشد.

Presenter جریان اطلاعات بین مدل و ویو را کنترل میکند و اطمینان حاصل میکند که داده ها به درستی به عقب و جلو منتق شوند و بروزرسانی ها در زمان واقعی اعمال میشوند این باعث میشود کنترل جریان اتفاق بیوفتد

به طور خلاصه presenter نقش مهمی در اجرای الگوی طراحی MPV ایفا میکند زیرا به عنوان پل بین دو لایه ی دیگر عمل میکند , ارتباط و تعامل بین آن ها را تسهیل میبخشد و در عین حال آن ها را از یکدیگر جدا نگه میدارد.

مزایا

MVP لایه presenter را از منطق تجاری و لایه Model جدا میکند و نگهداری و اصلاح و تغییر دادن در هر بخش را به طور مستق آسان تر میکند

همانند MVC در MVP نیز تست واحد را تسهیل میخشد که باعث به وجود آمدن کد با کیفیت تری میشود و در بخش مقیاس پذیری افزودن یا حذف کردن یا اصلاح یک بخش تاثیر زیادی روی بخش های دیگر نخواهد داشت در ننیجه نگهداری کد در زمان زیاد راحت تر میشود.

با تفکیک مسئولیت هر بخش الگوی MVP ما را به کدی تمیزنر و خواناتر میرساند که باعث میشود کار بین توسعه دهنگان بهتر شود و بهتر کدهای یکدیگر را درک نمایند

معایب

معایب MVP مانند MVC است که باعث پیچیدگی افزایش زمان و یادگیری زمان بر میشود زیرا اگر توسعه دهنده با انی الگو اشنا نباشد یادگیری برای او زمانبر است و روند توسعه کند خواهد شد.

MVVM

فناوری اپلیکیشن موبایل به سرعت در حال توسعه است. بر اساس داده های آماری، تعداد دانلود اپلیکیشن ها در سال 2023 به 257 میلیارد رسید. که نشان می دهد نیاز به اپلیکیشن های موبایل بسیار زیاد است. اندروید و iOS پرمصرف ترین سیستم عامل های تلفن همراه (OS) هستند و حتی 99 درصد از سهم بازار را در اختیار دارند. با این حال، افزایش تقاضا برای برنامه های کاربردی تلفن همراه با داده هایی همراه است که پاسخ های رضایت کاربران به برنامه های کاربردی ضعیف باعث حذف برنامه ها می شود. بنابراین اپلیکیشن های موبایل باید عملکرد خوبی داشته باشند تا رضایت کاربران را در استفاده از اپلیکیشن های موبایل افزایش دهند.

پس برای بهتر کردن کارکرد اپلیکیشن ها و رضایت کاربران یکی از راه ها استفاده از الگوی طراحی در حین توسعه است که یکی از آن ها MVVM میباشد.

یکی از دلایل اصلی استفاده از MVVM عملکرد خوب ان در CPU موبایل ها است.

MVVM به عنوان جایگزینی برای الگوهای MVC و MVP آمد SmallTalk این چارچوب را در دهه 1980 معرفی کرد.

سه جزء اصلی در الگوی MVVM وجود دارد: model، view و View Model.

علاوه بر درک مسئولیت های هر جزء، درک نحوه تعامل آنها نیز مهم است. در سطح بالا، view با view model در ارتباط است و ان را میشناسد و view model از model اگاه است اما نکته مهم این است که که model از view model اطلاعاتی ندارد و از هم جدا هستند .بنابراین view model ,view را از model جدا میکند و به مدل اجازه میدهد مستقل از نما تکامل یابد.

Model

مدل در MVVM (Model-View-ViewModel) مسئول نمایش داده ها و منطق تجاری برنامه است. این داده ها و رفتار برنامه را کپسوله می کند و با ViewModel تعامل می کند تا داده هایی را برای نمایش در View ارائه دهد. مدل معمولاً از کلاس‌هایی تشکیل می‌شود که نشان‌دهنده موجودیت‌ها یا اشیاء در برنامه هستند، مانند پروفایل‌های کاربر، محصولات یا تراکنش‌ها. همچنین شامل روش هایی برای بازیابی و دستکاری داده ها و همچنین انجام هرگونه عملیات منطقی تجاری ضروری است. در MVVM، مدل مستقل از لایه‌های View وViewModel است که امکان جداسازی بهتر نگرانی‌ها و نگهداری آسان‌تر از پایگاه کد را فراهم می‌کند. این جداسازی همچنین توسعه دهندگان را قادر می سازد تا به راحتی مولفه های Model را بدون اتصال محکم به سایر بخش های برنامه آزمایش و استفاده مجدد کنند.

View

View در MVVM (Model-View-ViewModel) وظیفه نمایش رابط کاربری به کاربر را بر عهده دارد. عناصر بصری برنامه مانند دکمه ها، فیلدهای متنی و تصاویر را نشان می دهد و برای بازیابی و نمایش داده ها با ViewModel تعامل دارد. View معمولاً با استفاده از طرح‌بندی XML در توسعه اندروید یا XAML در توسعه ویندوز پیاده‌سازی می‌شود. ساختار و ظاهر رابط کاربری را تعریف می کند، از جمله اینکه چگونه داده های ViewModel به کاربر نمایش داده می شود. در MVVM، View غیرفعال است و حاوی هیچ منطق تجاری یا کد دستکاری داده نیست. در عوض، به ویژگی ها و دستورات در معرض دید ViewModel متصل می شود تا نمایشگر خود را بر اساس تغییرات در داده های زیربنایی به روز کند. این تفکیک نگرانی ها امکان نگهداری و آزمایش پذیری بهتر پایگاه کد و همچنین همکاری آسان تر بین طراحان و توسعه دهندگانی که روی جنبه های مختلف برنامه کار می کنند را فراهم می کند.

View Model

ViewModel در MVVM (Model-View-ViewModel) به عنوان یک واسطه بین View و Model عمل می کند. مسئول نمایش داده‌ها و دستورات از Model به View، و همچنین مدیریت تعاملات کاربر و به‌روزرسانی مدل بر اساس آن است.

ViewModel حاوی ویژگی‌هایی است که نشان‌دهنده داده‌هایی است که باید در View نمایش داده شوند، و همچنین دستوراتی که اقداماتی را تعریف می‌کنند که می‌توانند توسط تعاملات کاربر ایجاد شوند. همچنین شامل منطق قالب‌بندی داده‌ها، انجام اعتبارسنجی و هماهنگی ارتباط بین View و Model است.

یکی از ویژگی های کلیدی ViewModel، اتصال داده است که امکان همگام سازی خودکار داده ها بین View و ViewModel را فراهم می کند. این بدان معنی است که تغییرات ایجاد شده در ViewModel به طور خودکار در View منعکس می شود و بالعکس، بدون نیاز به به روز رسانی دستی.

با جدا کردن منطق ارائه از منطق تجاری، ViewModel به بهبود قابلیت نگهداری، آزمایش پذیری و قابلیت استفاده مجدد کد کمک می کند. همچنین توسعه دهندگان را قادر می سازد تا با جدا نگه داشتن کدهای مرتبط با رابط کاربری از منطق برنامه اصلی، برنامه های ماژولار و مقیاس پذیرتری ایجاد کنند.

مزایا

اگر پیاده‌سازی مدل موجود منطق تجاری موجود را در بر بگیرد، تغییر آن می‌تواند دشوار یا خطرناک باشد. در این سناریو، view model به عنوان یک آداپتور برای کلاس های مدل عمل می کند و از ایجاد تغییرات عمده در کد مدل جلوگیری می کند. توسعه‌دهندگان می‌توانند بدون استفاده از view، تست‌های واحد را برای مدل view و مدل ایجاد کنند. تست‌های واحد برای مدل view می‌توانند دقیقاً همان عملکردی را اعمال کنند که توسط view استفاده می‌شود. رابط کاربری برنامه را می توان بدون دست زدن به مدل view و کد مدل دوباره طراحی کرد، مشروط بر اینکه نما به طور کامل در XAML یا C# پیاده سازی شود. بنابراین، یک نسخه جدید از view باید با مدل view موجود کار کند. طراحان و توسعه دهندگان می توانند به طور مستقل و همزمان بر روی اجزای خود در طول توسعه کار کنند. طراحان می توانند روی نما تمرکز کنند، در حالی که توسعه دهندگان می توانند روی مدلview و اجزای مدل کار کنند.

معایب

اتصال داده ها در MVVM گاهی اوقات می تواند بر عملکرد تأثیر بگذارد، به خصوص در سناریوهایی که مقادیر زیادی از داده ها نیاز به نمایش یا به روز رسانی مکرر دارند. ممکن است برای اطمینان از پاسخگو بودن و کارآمد بودن برنامه به بهینه سازی دقیق نیاز باشد. پس روی عملکرد تاثیر میگذارد

برخی از محیط‌ها و چارچوب‌های توسعه ممکن است پشتیبانی قوی ازMVVM ارائه نکنند، که می‌تواند اجرای موثر الگو را چالش‌برانگیزتر کند. توسعه دهندگان ممکن است نیاز داشته باشند برای غلبه بر این محدودیت ها به کتابخانه های شخص ثالث یا راه حل های سفارشی اعتماد کنند.

دیگر معایب آن هم مانند دو الگوی دیگر است که زمان و یادگیری است.

مقایسه بین الگو ها

MVC (Model-View-Controller):

در MVC، Controller به عنوان یک واسطه بین Model و View عمل می کند. کنترلر مسئول مدیریت ورودی کاربر، به‌روزرسانی مدل و به‌روزرسانی View بر اساس تغییرات مدل است. View تغییرات مدل را مشاهده می کند و بر این اساس خود را به روز می کند. MVC معمولا در چارچوب های توسعه وب مانند Ruby on Rails و ASP.NET استفاده می شود.

MVP (Model-View-Presenter):

در MVP، Presenter به عنوان یک واسطه بین Model و View عمل می کند. Presenter مسئول مدیریت ورودی کاربر، به روز رسانی مدل، و به روز رسانی view بر اساس تغییرات مدل است. View منفعل است و تعاملات کاربر را به ارائه کننده محول می کند. MVP معمولا در چارچوب های توسعه وب مانند GWT (Google Web Toolkit) استفاده می شود.

MVVM (Model-View-ViewModel):

در MVVM، ViewModel به عنوان یک واسطه بین Model و View عمل می کند. ViewModel داده‌ها و دستورات مدل را در معرض نمایش قرار می‌دهد، تعاملات کاربر را مدیریت می‌کند و مدل را بر این اساس به‌روزرسانی می‌کند. اتصال داده ها یکی از ویژگی های کلیدی MVVM است که امکان همگام سازی خودکار داده ها بین View وViewModel را فراهم می کند. MVVM معمولاً در چارچوب های توسعه برنامه های کاربردی مدرن مانند WPF (بنیاد ارائه ویندوز) و Xamarin استفاده می شود.

انتخاب بین الگوی طراحی

انتخاب بین الگوهای طراحی MVC , MVP و MVVM به عوامل مختلفی مانند الزامات پروژه، پشته فناوری مورد استفاده، بستگی دارد. و ترجیحات تیم توسعه.

MVC:

هنگام کار با برنامه های کاربردی وب یا فریم ورک هایی که از معماری MVC پیروی می کنند، مانند Ruby on Rails، ASP.NET یا جنگو، از MVC استفاده کنید. MVC برای پروژه هایی مناسب است که در آن تفکیک واضحی بین دستکاری داده ها (Model)، رابط کاربری (View) و منطق برنامه (Controller) وجود دارد. MVC انتخاب خوبی برای پروژه هایی است که از نظر به روز رسانی و تعاملات رابط کاربری به انعطاف پذیری نیاز دارند.

MVP:

هنگام توسعه برنامه های دسکتاپ یا برنامه های وب که نیاز به تعاملات پیچیده کاربر و منطق تجاری دارند، از MVP استفاده کنید. MVP برای پروژه هایی مناسب است که نیاز به تست پذیری و نگهداری بهتر وجود دارد، زیرا Presenter به عنوان یک واسطه بین Model و View عمل می کند. MVP انتخاب خوبی برای پروژه هایی است که به رویکرد ساختارمندتری برای مدیریت ورودی کاربر و به روز رسانی UI نیاز دارند.

MVVM:

هنگام توسعه برنامه‌های کاربردی مدرن با رابط کاربری غنی، مانند WPF، Xamarin یا Angular، از MVVM استفاده کنید. MVVM برای پروژه‌هایی مناسب است که به مکانیسم‌های اتصال داده برای همگام‌سازی خودکار داده‌ها بین View وViewModel نیاز دارند. MVVM انتخاب خوبی برای پروژه‌هایی است که جداسازی نگرانی‌ها و قابلیت نگهداری را در اولویت قرار می‌دهند، زیراViewModel داده‌های مدل را در معرض View قرار می‌دهد.

در نهایت، تصمیم به استفاده از MVC، MVP یا MVVM به الزامات خاص پروژه، آشنایی تیم توسعه با هر الگو و پشته فناوری مورد استفاده بستگی دارد. ارزیابی دقیق این عوامل قبل از انتخاب یک الگوی طراحی برای اطمینان از همسویی آن با اهداف و محدودیت های پروژه بسیار مهم است.

نتیجه گیری

در نتیجه، الگوهای طراحی MVC, MVP ,MVVM رویکردی ساختاریافته برای جداسازی نگرانی ها و بهبود قابلیت نگهداری کد در توسعه نرم افزار به توسعه دهندگان ارائه می دهند. هر الگو ویژگی های منحصر به فرد خود را دارد و برای انواع پروژه ها و فناوری ها مناسب است. MVC معمولاً در چارچوب‌های توسعه وب مانند Ruby on Rails و ASP.NET MVC استفاده می‌شود و انعطاف‌پذیری را در به‌روزرسانی‌ها و تعاملات رابط کاربری ارائه می‌دهد. از سوی دیگر، MVP برای برنامه های دسکتاپ یا برنامه های کاربردی وب با تعاملات پیچیده با کاربر ترجیح داده می شود و از طریق استفاده از یک ارائه دهنده واسطه، قابلیت تست و نگهداری بهتری را ارائه می دهد. MVVM برای برنامه های مدرن با رابط های کاربری غنی ایده آل است و از مکانیسم های اتصال داده برای همگام سازی خودکار داده ها بین View و ViewModel استفاده می کند. هنگام انتخاب بین MVC، MVP یا MVVM، توسعه دهندگان باید الزامات خاص پروژه خود، پشته فناوری مورد استفاده و ترجیحات تیم توسعه را در نظر بگیرند. با ارزیابی دقیق این عوامل، توسعه‌دهندگان می‌توانند در نهایت مناسب‌ترین الگوی طراحی را انتخاب کنند که با اهداف و محدودیت‌های پروژه‌شان همسو باشد.

منابع:

Architectural Patterns Revisited – A Pattern Language Paris Avgeriou Uwe Zdun CONCERT division Department of Information Systems Fraunhofer IPSI Vienna University of Economics and BA Darmstadt, Germany Vienna, Austria

Designing an MVC Model for Rapid Web Application Development Dragos-Paul Pop, Adam Altar 2014

ArchitectureRecoveryofWebApplications Ahmed E.Hassan and Richard C.Holt-Software architecture Group Department of Computer Science University of Waterloo

Applications Programming in Smalltalk-80 (TM): How to use Model-View-Controller (MVC) by Steve Burbeck, Ph.D

IBM Research Report Web-Application Development Using the Model/View/Controller Design Pattern Avraham Leff, James T. Rayfield IBM Research Division Thomas J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598

Principled Design of the ModernWeb Architecture Roy T. Fielding and Richard N. Taylor Information and Computer Science University of California, Irvine

Software Architecture Documentation in Practice: Documenting Architectural Layers Felix Bachmann Len Bass Jeromy Carriere Paul Clements David Garlan James Ivers Robert Nord Reed Little March 2000

httpaspiringcraftsman.com20070825interactive-application-architecture

httpsaddyosmani.comblogunderstanding-mvvm-a-guide-for-javascript-developers

httpsblog.iandavis.com200812what-are-the-benefits-of-mvc

httpsdotnet.microsoft.comen-usappsaspnetmvc

httpslearn.microsoft.comen-usarchiveblogsjohngossmanintroduction-to-modelviewviewmodel- pattern-for-building-wpf-apps

httpslearn.microsoft.comen-usdotnetarchitecturemauimvvm

httpslearn.microsoft.comen-usprevious-versionsmsp-n- pff649571(v=pandp.10)redirectedfrom=MSDN

httpslearn.microsoft.comen-ussamplesbrowseredirectedfrom=MSDN-samples 21-httpslearn.microsoft.comen-usxamarinxamarin-formsenterprise-application-patternsmvvm 22-httpsmartinfowler.comeaaDevuiArchs.html 23-httpspython.plainenglish.iothe-mvt-design-pattern-of-django-8fd47c61f582 23-httpsweb.archive.orgweb20200205124851httpwww.learnmvvm.com

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»