نیاز روز افزون به کامپیوتر و مکانیزه کردن و سپردن تقریبی تمامی امور به دست ماشین امری است که انکار ناشدنی است . در این بین تولید کنندگان نرم افزار نیز تلاش میکنند تا نرم افزاری تولید کنند تا بتواند اکثر نیاز های متقاضیان را به بهترین نحو ممکن تامین کند ودر همین راستا در تلاش هستند که روند تولید نرم افزار را به سمتی بکشانند که ساختار استاندارد و تائید شده ای داشته باشد.

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

نامبردن تمامی خصوصیات یک نرم افزار خوب در این مقال نمی گنجد اما تعداد محدود و مهمی از آنها عبارتند از:

قابل حمل بودن
قابل استفاده مجدد بودن
قابل تغییر بودن
بهینه بودن از لحاط حافظه و زمان (زمان مهمتر از حافظه)
و……

مسئله ؟
بهتر است وجود مسئله را با یک مثال نشان دهم

فرض کنید نرم افزاری برای شرکتی نوشتید که یه بخش آن مقدار سود وزیان شرکت را در سال های مختلف بر اساس ارقام بیان میکند . حال صاحب برنامه پس از مدتی ازشما می خواهد برنامه را طوری تغییر دهید که همین اطلاعات را به گونه های مختلف دیگه ای مثلا نمودار های مختلف ( میله ای ، دایره ای و …) در اختیار داشته باشد و یا حتی بخواهد انها را به فرمت خاصی و در فایل های خاصی ذخیره کند . در این مواقع چطور مشکل را حل میکنید؟

راه حل :
همانطور که گفته شد یکی از خصوصیات نرم افزار خوب قابل تغییر بودن آن میباشد. فرض کنید که برنامه را به این شکل طراحی کردید:

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

راه کار های نوین:

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

تعداد این لایه ها بسته به نرم افزار و طراحی میتواند ۲ ، ۳ ، ۴ یا ۵ لایه یا حتی بیشتر باشد . اما استاندارد ان که بیشتر از بقیه هم استفاده میشود ۳ لایه هست و به روشی که بر اساس این تئوری پیاده سازی میشود اصطلاحا ۳ Tire Programming گفته میشود.

در تئوری ۳ لایه ، لایه ها عبارتند از

Data Access layer
Business Logic Layer
Presentation Layer

توضیحات بیشتر و نحوه پیاده سازی روش فوق را به عهده خود خواننده میگذارم .

پس از مقدمه ای مختصر وارد بحث اصلی یعنی MVC (Model View Controller ) می شویم .
تذکر : قبل از پرداختن به مثال عملی ابتدا توضیحاتی در مورد معماری MVC می دهم برای آن دسته از عزیزانی که با این معماری آشنا نیستند ، طبیعی است که افرادی که مباحث تئوری این معماری را میدانند مستقیما میتوانند به بخش بعدی که به زودی آماده می شود، بروند .
MVC چیست ؟

MvC مخفف سه کلمه Model View Controller هست . در واقع MVC بر روی معماری های چند لایه ای جهت جداسازی قسمت های مختلف برنامه و به طور دقیق تر جدا کردن بخش ها منطقی برنامه اععم از دیتا ، permission ها ، چک کردن صحت داده ها و …. از لایه Presentation layer یا در واقع همان لایه ای که مستقیما با کاربر نهایی (End user) در ارتباط است ،قرار میگیرد.

پس بر اساس توضیحات فوق میتوانیم هر یک از بخش های معماری MVC یعنی Model و View و controller را به شکل زیر تعریف کنیم.

Model

در واقع بار اصلی معماری MVC بر عهده این بخش است . این بخش میتواند با داده ها در ارتباط باشد .الزاما منظور از داده حتما ارتباط با پایگاه های داده همچون MSSQL و Access و … نیست ، حتی منبع داده ها در بخش Model میتواند یک آرایه از اعداد و یا هر چیز دیگری باشد .
همچنین Model وظیفه چک کردن داده ها جهت صحت درستی داده ها را هم در بر عهده دارد (در این زمینه همکاری بیشتری با بخش Controller دارد) و همینطور وظایف دیگری که در مثال ها ی عملی که در آینده خواهم زد بیشتر آشنا خواهید شد.

View

این بخش که در واقع همان بخش Presentation Layer در معماری ۳ لایه میباشد وظیفه بر قراری ارتباط با کاربر نهایی و گرفتن داده از کاربر و نمایش داده های اماده با کاربراز طریق برقراری ارتباط با دو بخش دیگر یعنی Model و controller است . در واقع نکته مهمی که در بخش View باید ان را مد نظر داشت این است که این لایه مسئول کنترل صحت داده های وارد شده از طریق کاربر و همچنین مسئول صحت داده های نشان داده شده به کاربر نیست . در واقع این بخش یا داده های خام کار میکند . به عنوان یک مثال ساده خیلی از برنامه نویسان موقعی که در فرم Login برنامه ،کاربر کلمه عبور خود را وارد میکند ، در همان فرم Login اقدام به چک کردن پسورد مبنی بر صحت آن و … می کنند . که این عمل در معماری MVC قابل قبول نیست .
در واقع برای حل مسئله فوق در معماری MVC در فرم Login هنگامی که کاربر کلمه عبور را وارد کرد و دکمه Login یا ورود را زد ، کلمه عبور داده شده بدون هیچ گونه اعمالی اععم از Encrypt کردن و … به بخش های دیگر فرستاده میشود و فقط یک نتیجه ساده مبنی بر این که کاربر اجازه ورود دارد یا خیر را از بخش های دیگر دریافت میکند
که بر اساس ان اجازه ورود کاربر به برنامه داده میشود .

Controller

این بخش همانطور که از اسم ان مشخص است یه بخش کنترل کننده می باشد ، و در واقع واسطی بین دو بخش Model و View میباشد.

حال ببینیم روند اجرای برنامه در معماری MVC به چه نحوی خواهد بود .
در معماری MVC روند کلی برنامه (جزئیات را در ادامه خواهید دید) به این شکل است که کاربر تقاضای خود را از طریق واسط های برنامه نویسی (نظیر Form ها و User Control ها و .. ) از برنامه (از بخش View)درخواست می کند . بخش View در خواست ها را به بخش Controller فرستاده و این بخش با برقراری ارتباط با بخش Model در خواست های کاربر را پردازش کرده و پس از پایان پردازش زمانی که خروجی درخواست داده شده آماده گردید بخش Controller بخش View را آگاه میسازد تا خود را بر اسا س تغییرات جدید که اصطلاحا در معماری MVC به آن حال Model می گویند ، به روز سازد . در واقع چیزی که باعث میشود تا بخش Controller به بخش View اطلاع دهد که باید حالت جدید model را دریافت کند و خود را Update کند این است که بخش View باید قبلا خودش را در بخش Model اصطلاحا Register کرده باشد که البته عمل Register کردن توسط بخش Controller انجاام میگیرد . نحوه register کردن بخش View به معماری آن محیط و همچنین زبانی که توسط آن برنامه را گسترش میدهید و همچنین قابلیت های آن زبان بستگی دارد.

زبان C# در این زمینه قابیلت ها ی زیادی دارد که میتوان معمماری MVC را بر اساس آنها پیاده سازی کرد . به عنوان نمونه برای برای Register کردن بخش View میتوان از یک متد ساده مثلا به نام RegisterMe که یک View را که معمولا فرم میباشد را register میکند یا از Interface ها که انعطاف پذیری بالایی دارند وبا عث قدرتمند تر کردن برنامه نویس جهت پیاده سازی اهداف میشوند و …. استفاده کرد .

همچنین از برای آگاه سازی بخش View جهت به روز شدن از روش های مختلفی از یک متد ساده تا استفاده کردن از Delegate ها و Event ها استفاده کرد.
قصد دارم که مثال های متنوعی در این باره بزنم که سعی خواهم کرد ابتدا از روش های ساده شروع کنم و کم کم به سمت روش های حرغه ای تر حرکت کنم که همگی بتوانند از این معماری در برنامه های خودشون استفاده کنند.

حال ببینیم توضیحاتی که در مورد روند کلی یک برنامه که بر اسا س معماری MVC نوشته میشود در قالب یک نمودار به چه شکلی خواهد بود. نمودار را قدم به قدم رسم میکنم و ابندا از ساده ترین نمودار شرو ع خواه کرد.

گفتیم که معماری MVC بر اساس سه بحش یا سه لایه Modelو View و Controller بنا میشود . و همه چیز تحت نظر این سه لایه باید انجام شود.

حال اقدام به برقراری ارتباط بین این سه بخش (لایه) بر اساس توضیحاتی که دادم میکنم.
خیلی از مقاله ها شروع معماری را از بخش کنترلر میدانند در واقع دست هم میگویند چون در نهایت بخش کنترلر است وظیفه handle کردن ابزار های مختلف مثل موس و .. را دارد. پس میتوان نمودار فوق را به شکل زیر کامل کرد:

اما من در نموادر فوق و بر اسا توضیحاتی که دادم فرض میکنم که کاربر درخواست هایش را از طریق فرم ها وارد کرده و منتظر نتیجه اطلاعات میباشد.

مراحل را به ترتیب عملیت و با شماره روی شکل نشان دادم .

توضیحات شکل بر اساس روند جریان برنامه:
مرحله ۱) در این مرحله درخواست ها از سمت کاربر نهایی به ویو فرستاده میشود . پس جهت جریان اطالاعات در این مرحله از سمت End user به سمت View می باشد.

مرحله ۲ ) در این مرحله کاربر درخواست خود را از طریق بخش View اعمال میکند .همانطور که گفته شد ویو مسئولیتی در قبال داده های وارد شده معمولا ندارد ،پس در خواست کاربر را به بخش کنترلر می فرستد. همچنین در همین مرحله ویو خودش را register می نماید تا بتداند اطلاعات جدید را دریافت نماید .جهت حرکت در قسمت ۱ از سمت View به سمت Controller میباشد.

مرحله ۳) پس از اینکه در خواست کاربر از View به Controller رسید و Controller بخش View را رجیستر کرد ، درخواست را به مدل داده و از مدل میخواهد که بر اساس درخواست کاربر به حالت جدید رفته و خود را به روز نماید. جهت جریان اطلاعات در این مرحله از سمت Controller به سمت Model میباشد.

مرحله ۴) پس از اینکه مدل به درخواست ها رسیدگی کرد ، و به حالت جدید رفت این رفتار را به کنترلر پیغام میدهد . (همچنین اگر خطایی در این بین اتفاق بیفتد نیز کنترلر مطلع و به طبع آن در مرحله بعدی ویو نیز مطلع میگردد) .جهت جریان اطلاعات در این مرحله از سمت Model به سمت Controller میباشد.

مرحله ۵) در این مرحله ، کنترلر موظف است که پیغامی به ویو بفرستد مبنی براینکه مدل تغییر کرده و به حالت جدید رفته است . این تغییر حالت الزاما دریافت داده های جدید از دیتا بیس و … نیست بلکه هر نوع تغییری میتواند باشد ، مثلا یک Exception رخ داده است و … جهت جریان اطلاعات در این مرحله از سمت Controller به سمت View می باشد.

مرحله ۶) در این مرحله ویو موظف است اطلاعات جدید و حالت جدید مدل را از مدل تقا ضا کند . جهت جریان اطلاعات در این مرحله از سمت View به سمت Model می باشد.

مرحله ۷) در این مرحله اطلاعات تغییر یافته و به طور کلی حالت جدید مدل (Model State) به ویو اطلاعا داده میشود. جهت جریان اطلاعات در این مرحله از سمت Model به سمت View میباشد.

مرحله اطلاعات و تغییرات جدید سیستم که بر اساس در خواست مدل ایحاد گردیده به کاربر نهایی نشان داده میشود . باز هم الزامی نیست که حتما داده های جدید به کاربر نشان داده شوند ، این اطلاعات حتی میتواند یک پیغام مبنی بر اینکه یک Exception رخ داده است باشد. جهت جریان اطلاعات در این مرحله از سمت View به سمت End User است