بررسی معماری MVC - قسمت اول

این مقاله از وب سایت http://www.aachp.ir انتخاب شده است.

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

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

اجازه دهید ببینیم خصوصیات یک نرم افزار خوب چیست؟

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

1 - قابل حمل بودن

2 - قابل استفاده مجدد بودن

3 - قابل تغییر بودن

4 - بهینه بودن  از لحاط حافظه و زمان (زمان مهمتر از حافظه)

۵ - . . .

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

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

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

فرض کنید که برنامه را به این شکل طراحی کردید:

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

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

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

تعداد این لایه ها بسته به نرم افزار و طراحی می تواند 2، 3، 4 یا 5 لایه و یا حتی بیشتر باشد. اما استاندارد آن که بیشتر از بقیه هم استفاده می شود 3 لایه است و به روشی که بر اساس این تئوری پیاده سازی می شود اصطلاحا برنامه نویسی سه لایه - Three Tire Programming - گفته می شود.

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

•  Data Access layer
•  Business Logic Layer
•  Presentation Layer

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

پس از مقدمه ای مختصر وارد بحث اصلی یعنی MVC یا Model View Controller می شویم .

MVC چیست؟

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

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

1 ) Model: در واقع  بار اصلی معماری MVC بر عهده این بخش است. این بخش می تواند با داده ها در ارتباط باشد. الزاما منظور از داده حتما ارتباط با پایگاه های داده همچون MSSQL و Access و . . . نیست. حتی منبع داده ها در بخش Model می تواند یک آرایه از اعداد و یا هر چیز دیگری باشد.

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

2 ) View: این بخش که در واقع همان بخش Presentation Layer در معماری 3 لایه می باشد وظیفه برقراری ارتباط با کاربر نهایی و گرفتن داده از کاربر و نمایش داده های آماده با کاربر از طریق برقراری ارتباط با دو بخش دیگر یعنی Model و Controller را دارد. در واقع نکته مهمی که در بخش View باید آن را مد نظر داشت این است که این لایه مسئول کنترل صحت داده های وارد شده از طریق کاربر و همچنین مسئول صحت داده های نشان داده شده به کاربر نیست. در واقع این بخش یا داده های خام کار می کند.

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

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