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

مفهوم معماری اپلیکیشن ها

در همه موارد سیستم های پیچیده،

1.مدل معماری Model-View-Controller (MVC) به سبک Metaphor

از محبوب ترین و گسترده ترین مدل های معماری اپلیکیشن ها، مدل  الگوی Model-View-Controller است. هرچند بصورت دقیق این مدل تعریف نشده و به روش های متفاوتی تاکنون پیاده سازی شده است. خصوصا در چارچوب برنامه های وب (web application framework) که براساس اصول جداسازی و نگرانی های پروژه و در بینش بنیادی که پایه و اساس کلیه بخش های دیگر برنامه، به ویژه برای رابط کاربر، بر روی مدل استوار است. درنتیجه، حتی اگر رویکرد MVC همچنان تعریف دقیقی از مدل نداشته باشد، ما آن را یک رویکرد مبتنی بر مدل (model-based) می نامیم.

مطابق گفته ویکیپدیا، اولین معماری MVC با Smalltalk-76 توسط Trygve Reenskaug در سال 1970 منتشر شده بود.

خلاصه ای از مفهوم MVC: یک برنامه با تقسیم بندی سه لایه است که لایه یکم بخش هایی است که نشان دهنده مدل زیربنایی دامنه برنامه است بخش دوم مدلی که به کاربر نمایش داده می شود و بخش سوم رابط کاربری کار با آن است. نویسندگانی که از اصطلاح "MVC metaphor" استفاده می کنند، به رویکردی اشاره می کنند که به برنامه نویسان این اجازه را می دهد که مدل برنامه را از ابتدا توسط تعریف کلاس های جدید که مجسم کننده اطلاعات دامنه-مشخص برنامه است، بنویسند.

نکته اینجاست که مدل تعریف شده شامل کلاس هایی است که اطلاعات مورد نیاز دامنه را می گیرد. ما آن ها را کلاس های مدل (model classes) می نامیم. نکته دیگر این است که در ابتدای رویکرد MVC، هیچ مفهومی به درستی بخش UI یا همان رابط کاربری را به درستی تعریف نکرده بود. تعریف View اینگونه است که خروجی باید فقط رابط کاربری یا همان UI باشد، درحالیکه از ورودی های کاربر جدا شده باشد و تحت پوشش Controller قرار گیرد. در واقع منعکس کننده این نیست که رابط کاربری چگونه سازماندهی شده است: درواقع ترکیب خروجی فرم ها با فرم هایی ورودی کاربر دقیقا به مانند دو طرف سکه است. یک رابط کاربری عمومی شامل دو خروجی است (اطلاعات خروجی فراهم شده توسط کاربر) و ورودی (اطلاعاتی که توسط ورودی ها فراهم شده است، درست به مانند اتافاقاتی که توسط کاربر انجام شده است)

نسخه اصلی توسعه داده شده Smalltalk MVC metaphor برای رابط کاربری صفحه های monochromatic بدون هیچ مفهوم عمومی رویداد های UI بود. این ممکن است توضیح داده شود که چطور آن ها مفهوم کامل UI را در نظر نمی گیرند. درحالیکه آن ها حالت اشیاء را در مدل و حالت اشیاء را در UI متفاوت می بینند، که هر دو محدوده user session هستند، آن ها نمی توانند تفاوتی میان حالت مدل و حالت بانک اطلاعاتی قائل شوند.

در مقاله GUI Architectures (2006)، که توسط Martin Fowler منتشر شده بود، اصول MVC را به شکل زیر تعریف کرد:

1. لایه مدل و رابط کاربری از یک دیگر جدا باشند

2. همچنین رابط کاربری را به دو بخش View و Controller تقسیم می کنیم.

3. View ها با مدل Sync می شوند. (مکانیزم Data Binding)

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

اصطلاح MVC امروزه بصورت وسیعی استفاده می شود، مخصوصا توسط چارچوب برنامه های وب، اما با معانی متفاوتی منسوب به "M"، "V" و "C". بصورت معمول، View به کدهای HTML که براساس فرم هست،  معنی شده است. و controller به مفهوم اتصال بخش مدل به View است.

برای مثال در الگوی Active Record که تأثیر گرفته از چارچوب Ruby-on-Rails که آداپته شده توسط خیلی از چارچوب های برنامه های وب مانند CakePHP، مدل یک نمایشگر مستقیم از شماتیک سیستم بانک اطلاعاتی دارد، که هر موجودیت (entity) جدول از بانک اطلاعاتی نمایشگر یک کلاس مدل است که از متد های data manipulation به ارث برده است که برای انجام 4 عمل اصلی به کار می رود (CRUD: Create – Read – Update – Delete). در این رویکرد table-to-model-class، مدل بستگی دارد به شماتیک زیرساخت بانک اطلاعاتی و همچنین ارتباط نزدیکی با زیرساخت تکنولوژی ORM دارد، درحالیکه این ممکن است مناسب باشد برای متدولوژی database-first development، جایی که یک بانک اطلاعاتی SQL حکم پیدایش یک برنامه را دارد.

همچنین در چارچوب هایی که بر اساس ORM Annotation هستند، مانند JavaEE با JPA annotation، چارچوب سی شارپ در ASP.NET MVC به همراه Entity FrameWork و Data Annotations، یا PHP Framework Symfony به همراه Doctrine annotations. واژه مدل اساس و پایه تکنولوژی ORM است و این دو با یکدیگر اجین شده اند. درنتیجه مدل وابسته است به استفاده از تکنولوژی ORM. همه این چارچوب ها توسط رویکرد Data Mapper برای انجام عملیات CRUD با استفاده از ORM Annotation ها استفاده می شوند.

2.پیاز معماری Metaphor

اصطلاح پیاز معماری اولین بار توسط Jeffry Palermo در سریال پست های بلاگش در سال 2008 مطرح شد. اصل مهم استفاده از این معماری Metaphor،

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

2) اساسی ترین بخش، مدل است که پیاده ساز داده ی برنامه در فرم مدل کلاس ها است درحالیکه محل نگهداری داده جدا شده است و نباید با مدل همراه شود.

در حقیقت، Palermo و پیروانش مفاهیم خیلی بیشتری در اصلاح معماری Metaphor قرار داده اند، مانند استفاده از Repository Interface ها و Service Interface ها، اما اینطور تصور نمی شود که مفاهیم پایه ای برای پیاز Metaphor باشد. همچنین آن ها از یک اصطلاح متفاوت استفاده می کنند. زمانیکه آن ها از اصطلاح Domain Model استفاده می کنند به جای Simply Model، مفهومی گیج کننده به وجود می آید با Implementation of data model یا پیاده سازی یک داده مدل که ممکن است خودش مشتق شود به domain model information. این پایه و اساس توسعه سلسله مراتبی در مهندسی نرم افزار بوده است.

3.الگوی معماری Model-Storage-View-Controller یا MSVC

تا اینجا سه حالت مهم و اصلی بررسی شد:

1) کلاس های مدل، که پیاده ساز data model برنامه هستند و تعریف کننده data structure

2) سیستم data storage، که معمولی است اما نیازی واجبی نیست، یک سیستم بانک اطلاعاتی SQL است.

3) UI یا رابط کاربری، که شامل هر دو اطلاعات ورودی و خروجی است. برای مثال کاربر توسط فعالیت هایی  در فرم که از UI Event ها استفاده می کند، اطلاعاتی وارد می کنند، یا رویداد موس.

معماری MSVC پیرو مفهوم اصلی و پیاز مدل Metaphor است به وسیله جدا سازی لایه مدل نه فقط لایه رابط کاربری. اما همچنین از لایه Data Storage و مدل که اساسی ترین بخش است، نباید به هیچ بخش دیگری وابسته باشند.

ViewModel .4 متمایز کننده منطق و فیزیک رابط کاربری

ایده مدل منطقی رابط کاربری، همچنین ViewModel گفته می شود، اولین بار توسط Martin Fowler در پست Presentation Model در سال 2004 مطرح شد، جایی که او اظهار داشت  viewmodel حالت و رفتار View را در دست می گیرد. درنتیجه این معنی را می دهد که محتوای منطقی از UI بصورت انتزاعی در خارج از فیزیک UI باید قرار بگیرد که نمایشگر فیلد های منطقی رابط کاربری و دستورات (commands) است. فیلد های منطقی رابط کاربری نمایش داده می شود فرمی از ویجت های رابط کاربری که ممکن است حالات خودشان را داشته باشند درحالیکه دستورات منطقی رابط کاربری در فرم مناسبی از رویداد های رابط کاربری نمایش داده می شوند.

در سال 2005 مفهوم View model توسط John Gossman از مایکروسافت تطبیق داده شده است در بلاگش با عنوان Introduction to Model/View/ViewModel pattern for building WPF Apps و مخففش معروف شده است به MVVM.

در یک رابط کاربری برای مدیریت داده 4 عمل اصلی CRUD: Create-Read-Update-Delete یک کلاس ViewModel دقیقا به یک کلاس مدل محدود می شود اما می توانست پشتبیانی شود بیشتر از یک کلاس View. یک کلاس View model خواصی دارد که باید محدود شود به ویجت هایی که View پشتیبانی می کند با استفاده از data binding یک طرفه یا دو طرفه و متدهایی که محدود شده اند برای اجرای دستورات یا همان command binding.

بصورت معمول، بیشتر فیلد های view مستقیما با خواص در ارتباط هستند و زیرساخت کلاس مدل هستند، همچنین آن ها ممکن است نام های متفاوتی داشته باشند. برای این فیلد ها یا خواص view model یک data binding به یک خاصیت متناظر نیاز دارد. اما کلاس view model ممکن است همچنین خواص بیشتری داشته باشد، بعضی از آن ها نمایش گر فیلد های view  هستند که محدود نمی شوند به خاصیت مدل، درحالیکه بقیه ممکن است فیلد های کمکی برای نمایش داده نشدن در رابط کاربری به کار روند.

مزیت های اصلی view model عبارت است از:

1) تسهیل طراحی رابط کاربری

2) تسهیل تست منطق رابط کاربری

3) تسهیل نگهداری رابط کاربری

آموزش asp.net mvc