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

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

حال ببینیم روند اجرای برنامه در معماری 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 کردن ابزارهای مختلف مثل موس و . . . را دارد.

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

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

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

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

مرحله 2: در این مرحله کاربر درخواست خود را از طریق بخش View اعمال می کند. همانطور که گفته شد ویو مسئولیتی در قبال داده های وارد شده معمولا ندارد. پس در خواست کاربر را به بخش کنترلر می فرستد. همچنین در همین مرحله ویو خودش را Register می نماید تا بتواند اطلاعات جدید را دریافت نماید. جهت حرکت در قسمت 1 از سمت View به سمت Controller می باشد.

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

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

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

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

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

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