نگاهی اجمالی به تاریخچه تئوری های مشهور Design Pattern (از آرشیو گذشته در 28 ژانویه 2014)

 در اوایل دهه 90 میلادی و پس از انتشار تئوری وب توسط Tim Berners-Lee که در فاصله بسیار کوتاهی با کمک Robert Cailliau در قالب پروژه World Wide Web به مرحله اجرا رسید، طولی نکشید که سطح توقع و انتظار از وب تا حد تبدیل به یک Platform جهت اجرای Application ارتقا پیدا کرد و ماهیت Stateless بودن این Platform لاجرم مستلزم معماری ویژه ای بود که در مقایسه با برنامه های Desktop تفاوت های برجسته ای داشت. به طور دقیق از سال 1995 رسما مفهوم Web-based Applications مصطلح گردید.
هدف من از ببان اجمالی این تاریخچه کوتاه ، مروری بر این واقعیت می باشد که مفهوم Design Patterns مدتها قبل از ظهور وب و به دلیل احساس نیاز شدیدی که مبنی بر Modular کردن و تخصصی نمودن وظایف کد و امکان استفاده از مفهومی نظیر Encapsulation و بسته بندی قطعات کد به نحوی که به طور مستقل در سایر سناریوها نیز به کار گرفته شود، وجود داشت.
دغدغه جدا سازی وظایف اصلی یک Application باعث شده تا مدلهای متعددی برای دستیابی به هدف فوق ایجاد و منتشر شود که مدلهای n-Layers یا چند لایه ، مدل و معماری MMVM ، MVC و ... ار جمله این موارد میباشند.
در فاصله زمانی که اشاره کردم مخصوصا در ارتباط با وب و ظهور اولین web server ها و مرورگرها مجموعه ای از رویدادها و دستاوردهای شگفت انگیزی وجود دارد که ذکر جزییات آن در این فرصت مقدور نیست. در صورت تمایل به دریافت اطلاعات بیشتر میتوان به اولین وب سایت جهان به آدرس
http://info.cern.ch/
و یا
http://public.web.cern.ch/
مراجعه نمود. نکته قابل توجه و جالب اینکه این سایت بعد از گذشت بیشتر از 20 سال هنوز اصالت و طراحی اولیه خودش را حفظ کرده است و یک تاریخچه مفید از مراحل رشد و ترقی این پروژه تاریخی را ارائه می کند.
اما با توجه به برخی ابهامات و سوالهای مطرح شده درباره معماری MVVM و یا یکی از مشتقات آن یعنی MVP یا MVC شاید مرور تاریخچه ای اجمالی از مراحل تدوین آنها خالی از لطف نباشد.
اگر برای بررسی مفهوم Design Pattern، ریشه آن و تلاشهای انجام شده مرتبط با آن به منابع معتبر مراجعه کنیم، بی تردید با نام دکتر Trygve Reenskaug روبرو خواهیم شد.
ایشان یکی از نوابغ موسسه مشهور Xerox PARC میباشند که در سال 1973 به عنوان سرپرست و یکی از اعضای تیم تحقیقاتی SmallTalk برای تدوین راهکارها و مفاهیمی برای استقلال بخشهای متفاوت کد، بر اساس وظیفه ای که برای کد در نظر گرفته شده است، فعالیت های بسیار قابل توجهی داشته است این تلاشهای مستمر، منجر به ایجاد یکی از مهمترین و مشهورترین تئوریهای موجود در زمینه Design Pattern گردید و خیلی زود با نام Model View Controller یا به اختصار MVC منتشر گردید. SmallTalk اولین کامپایلر شیء گرای محض یا Pure Object Oriented می باشد که متاسفانه تا به امروز افتخار زیارت این موجود افسانه ای و دوست داشتنی نصیب من نشده است!!.
عبارت محض در توصیف این کامپایلر اشاره به این واقعیت بسیار مهم می باشد که بر خلاف سایر کامپایلرهای شی گرا، (مثلا C++، ) امکان کد نویسی به روشهای سنتی Procedural در این کامپایلر وجود ندارد.
حاصل تحقیقات دکتر Reenskaug به تفصیل در heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html قابل مشاهده می باشد. ایشان در قسمت مهمی از این تحقیق جامع چنین توصیفی از تئوری تازه تولد یافته و چالش های نامگذاری آن دارند:

"MVC در حقیقت یک معماری نرم افزار است که به عنوان یک راه حل عمومی بویژه برای برنامه نویسانی که با حجم متنابهی از کد و یا داده ها و اطلاعاتی با ساختارها و ارتباتاط پیچیده روبرو هستند، کاربرد داشته و مفید واقع خواهد شد.
در این مدل تاکید بسیار زیادی بر جدا سازی جزییات منطق ارائه اطلاعات و همه آن چیزی که به عنوان رابط کاربر، موظف به برقراری ارتباط با کاربر و دریافت فرامین او می باشد، شده است.
یکی از چالش ها بعد از تکمیل مدل نهایی، انتخاب یک نام مناسب برای این مدل تازه تولد یافته بود. ابتدا از اصطلاح Model-View-Editor استفاده میکردیم. اما بعد از مباحث متعدد و طولانی که با همکار محترم Adele Goldberg برگذار گردید، پرونده نامگذاری این مدل با انتخاب نام Model View Controller. یا به اختصار MVC برای همیشه بسته شد."

چناتچه از نامگذاری این مدل نیز کاملا مشهود است اجزای اصلی در این مدل عبارتند از Model، View و Controller.

طولی نکشید که این نظریه خود مبنایی برای تفسیر و روایتهای متنوعی گردید که کمابیش برداشتهای متفاوتی از این مدل را ارائه میکردند. به عنوان نمونه مدل Model View Presentation یا MVP یکی از همین موارد می باشد که البته به دلیل تاکید بیشتر در لایه Presentation بیشتر به عنوان مدلی برای ایجاد برنامه های Thick Client که از کتابخانه های توابع رابط کاربر گرافیکی غنی تر و پیشرفته ای بهره می برند، تلقی می شود.
چنانچه گفته شد صرفنظر از برخی جزییات در همه این مدلها خصوصا در MVC اجزای اصلی مدل (چنانکه نام برده شد) یکسان است و البته میتوان به بارز ترین خصوصیات آن به صورت بسیار اجمالی اشاره نمود. اما قبل از معرفی این اجزا لازم میدانم به نکته بسیار مهمی اشاره کنم:

"مدل MVC نیز نظیر اغلب مدل های دیگر با پیش فرض مستقل بودن از Platform و زبان برنامه نویسی ایجاد شده است. من نیز در ابتدا با معرفی عناصر اصلی این مدل، موارد مذکور را رعایت خواهم نمود. اما در نهایت به نظر میرسد برای توصیف دقیق تر جزییات نیاز به ارائه مثالهایی در یک Platform و با بهره گیری از یک زبان مشخص ، اجتناب ناپذیر باشد.
در مدل MVC جزء موسوم به Controller موظف است در یکی از مهمترین وظایف اصلی خود، مفهومی به نام Command را پیاده سازی نماید به نحوی که View قادر به احضار و اجرای فرامین باشد."

در پلتفرم های جدیدتر Silverlight و WPF این مفهوم بنا بر برخی ملاحظاتی که از ابتدای طراحی WPF در نظر بوده (جزییات و دلایل این اختلاف سلیقه را میتوانید به طور مشروح در وبلاگ شخصی مارتین فاولر که خود یکی از تئوریسین ها و طراحان اصلی WPF میباشد مطالعه نمایید) با نام ViewModel نامگذاری شده و مطابق یک روال ثابت، دستیابی به اهداف مورد نظر جهت پیاده سازی Command صرفا با Implement نمودن اینترفیس ICommand قابل دستیابی می باشد. از این به بعد من به مجموعه تکنولوژی های Silverlight و WPF به صورت WPF رجوع خواهم کرد مگر آنکه تفاوتی وجود داشته باشد که آن را صریحا مشخص خواهم نمود.
اجرای هر Command به طور نسبتا رایجی منجر به تغییر یا تعویض مفهوم بسیار مهمی به نام State میگردد. طراحی View به نحوی که متناسب با تغییرات State ، آرایش و چیدمان عناصر رابط کاربر متفاوتی را متناسب با State جدید ارائه نماید، استراتژی بسیار مناسبی است و در این مدل نیز بر آن تاکید ویژه ای شده و توصیه میگردد.
همچنین در Wpf به طور معمول View کلاسی مشتق شده از Control یا UserControl است که مطلوب است Consructor این کلاس تنها شامل یک فراخوانی InitializeComponent (که اجباری نیز هست) باشد. ارتباط View با ViewModel صرفا با مکانیسم کلیدی و بسیار مهم DataBinding برقرار می شود و اغلب رابطه View با ViewModel یک رابطه یک به یک میباشد.
وظیفه Model به طور مشخص ایجاد مکانیسم هایی جهت آگاه نمودن (Notify) اجزای View و Controller است. در Silverlight و WPF این امر با Implement نمودن اینترفیسهای INotifyPropertyChanged و INotifyCollectionChanged میسر میگردد. تجربه شخصی من نشان میدهد که در برخی حالت های خاص با نوعی Data Source مواجه خواهیم شد که امکان اضافه نمودن قابلیت Notify مستقیما میسر نیست. در این وضعیت طراحی ViewModel باید به گونه ای باشد که این نقیصه را جبران کرده و مثلا به صورت یک Wrapper شرایطی فراهم کند که View قادر باشد با بهره گیری از DataBinding وظایف خود را بدون اشکال انجام دهد.
تغییرات View در واکنش به تعویض State مفهوم خیلی غریب و دور از ذهنی نیست. اما به عنوان مثالی برای درک چگونگی تغییر در ViewModel متناسب با تعویض State میتوان تغییر در مجموعه Command هایی که در حال حاضر در دسترس View میباشند را بیان نمود.
البته در حال حاضر (یعنی در WPF 4.5 و Silverlight 5.0) هیچ Template و الگوی استاندارد برای ایجاد یک قالب پروژه سازگار با معماری MVVM وجود ندارد و برای جبران این نقص باید از Library های جداگانه استفاده نمود که یکی از مشهورترین آنها Prism می باشد که در https://compositewpf.codeplex.com/ قابل دسترس بوده و اتفاقا مستندات بسیار کاملی هم همراه این پروژه Open Source میباشد. نسخه 4.2 در حال حاضر اختصاصا برای Framework 4.5 طراحی شده و حتی نسخه اختصاصی آن برای Windows 8 Store Application نیز به تازگی منتشر شده است.
اما یک سوال اساسی در اینجا مطرح میشود و آن اینکه در مقایسه با برنامه های Desktop و با وجود خصلت های متفاوتی که در برنامه های Web-based وجود دارد، آیا امکان استفاده از این مدل در برنامه های مبتنی بر وب یا به طور مشخص در Asp. Net وجود دارد؟
برای پاسخ به سوال مطرح شده به نظر میرسد نگاهی به معماری و نحوه ایجاد برنامه های وب, حداقل با شروع از مقطع زمانی ظهور تکنولوژی Net. ضروریست.
راه حل Microsoft برای تهیه برنامه های وب، در دات نت، مجموعه ای از تکنولوژی ها و ابزارهای خاصی بود که امروزه با نام Classic Asp .Net شناخته میشوند. این تکنولوژی بر اساس مفهومی به نام ViewState طراحی شده است که به عبارت ساده تر تلاشی است جهت غلبه بر مشکلات ناشی از Stateless بودن خود platform وب. به طور مشخص ViewState یک Container ویژه ایست که وضعیت و داده های State جاری در یک Web Form. را حفظ کرده و کل این Container در خلال مکانیسم Postback به وضعیت جدید همان فرم یا یک Web Form جدید منتقل میگردد. این مفهوم تا حدود زیادی حالت موجود در برنامه های Desktop را شبیه سازی کرده و برنامه نویسان را از درگیر شدن با جزییات و تبعات Stateless بودن وب، دور نگاه میدارد.
در اینجا منظور از Postback دقیقا اشاره به یک واحد از Request/Response می باشد که با ایجاد یک Request در Browser و انتقال آن در قالب یک بسته اطلاعاتی ویژه با استفاده از پروتکل HTTP یا HTTPS آغاز شده و بسته مذکور در Web Server دریافت و پردازش میگردد. به طور معمول نتیجه حاصل از پردازش مجددا با استفاده از پروتکل های نام برده شده به Client یا به طور دقیق تر همان Browser، توسط مفهومی به نام Response منتقل میگردد.
در مراحل مختلف این عملیات برنامه نویسان با بهره گیری از مفهومی به نام Event در جریان تغییر جزییات این مراحل قرار میگیرند که به طور معمول با استفاده از مکانیسم Event Handling واکنش ها و عکس العمل های مورد نیاز خود را اعمال می نمایند.
در صورت نیاز به کنترل بیشتر و مدیریت سطوح بالاتر حتی تا حدی که امکان پردازش Request قبل از مکانیسم های پردازش Web Server آغاز شود روش های بسیار موثری نظیر استفاده از Dynamic Request Handling و Modules وجود دارد که دقیقا قابلیت های ISAPI Programming را بدون مواجهه با جزییات مشکل آن میسر میسازند.
این روشها سالهای نسبتا طولانی توسط برنامه نویسان استفاده شده و اتفاقا از محبوبیت زیادی نیز برخوردار می باشند. و قطعا همه دوستان و همکاران محترم بارها از آن در پروژه های گوناگون استفاده نموده اند.
بزرگترین نقد و یا اشکالی که معمولا در باره این روش مطرح میشود این است که چون اساسا در ظاهر برنامه نویسان کدهای مرتبط با Business Logic و Data Access را حتی به همراه کدهای کنترل تراکنشهای مورد نیاز UI در Code Behind ایجاد میکنند، بنابراین به هیچ وجه امکان دستیابی به اهدافی که مثلا در MVC تشریح شده وجود ندارد. به عبارت ساده تر گفته میشود که این تکنولوژی فاقد مکانیسم ها و ابزار لازم جهت دستیابی به هدف Reusability میباشد.
بنا بر تجربه شخصی من، این انتقاد صحیح نیست. شاید تعمیم ایده های مطرح شده در MVC مشخصا در Classic Asp. .Net میسر نباشد اما با اتخاذ روشهای صحیح و مناسب امکان ایجاد برنامه هایی با کد Well Defined در این تکنولوژی امکان پذیر بوده و نمونه های متعددی از آن وجود دارد.
اما استفاده از MVC در وب مبحث دیگریست. برای دستیابی به این هدف، Microsoft با معرفی و انتشار Asp. NET MVC ضمن باز نگری در تکنولوژی قبلی راهکارهای جدیدی متناسب با مدل MVC ارائه نمود. نکته ظریف و بسیار مهمی که در اینجا باید به آن توجه کنیم این است که این "تکنولوژی نه به عنوان یک جایگزین یا Replacement بلکه به عنوان یک راهکار Alternative ارائه شده و مایکروسافت بارها بر روی این نکته تاکید کرده است. قبل از بررسی این تکنولوژی باید متذکر شوم که بنا بر تجربه شخصی پیشنهاد من در صورت نیاز به استفاده از مدل MVC استفاده از تکنولوژی های Silverlight و WPF میباشد که به دلیل بهره گیری از مفاهیم بسیار قدرتمندی مثل حداکثر توانایی در ایجاد UI با استفاده از Declarative Programming که با تکنولوژی Extensible Application Markup Language یا به اختصار XAML (که زمل یا ZAMEL تلفظ میشود) پیاده سازی شده، همچنین مکانیسم های پیشرفته، کارآمد و نوین Data Binding، و. .. دارای حداکثر سازگاری با مدل MVC بوده و تردیدی وجود ندارد که تا سالهای زیاد به عنوان تکنولوژی برتر و توصیه شده مایکروسافت جهت ایجاد برنامه های کاربردی Client/Server در مقیاسهای متنوع مطرح خواهد بود.

در Asp. Net MVC , مایکروسافت دو تغییر بنیادی ایجاد نمود تا این تکنولوژی قابلیت پیاده سازی اهداف MVC را دارا باشد. اول اینکه پروسه postback سنتی و کلاسیک،به طور کلی حذف شده و از Representational State Transfer (که به اختصار REST نامیده میشود) استفاده نمود. دوم اینکه بر خلاف تکنولوژی کلاسیک که در آن الزاما هر URL متناظر با یک. Resource تلقی میشود ( البته به استثنای استفاده از Dynamic HTTP Handler در ASP .NET Web Form کلاسیک که در شرایط خاص این تناظر یک به یک می تواند وجود نداشته باشد و اتفاقا MVC هم با همین روش یعنی HTTP Handler در لایه های میانی و بالای پردازش IIS مستقر میشود) ، در تکنولوژی جدید هر URL صرفا بخشی از Request تلفی شده که معنا و مفهوم دقیق آن کاملا وابسته به نوع پردازشی میباشد که در Controller در نظر گرفته شده است.
در حال حاضر آخرین روایت این تکنولوژی ( روایت 4) علیرغم آنکه همه انتظارها را برآورده نکرده است اما به هر حال به نظر میرسد که اعضای تیم طراحی به سرعت به اهداف مدل نزدیک شده و یک نگاه اجمالی به مستندات و مثالهای مفید آموزشی نشان میدهد که بسیاری از سناریوهای متنوع با تکنولوژی جدید قابل پیاده سازی میباشند.
اما در Silverlight و WPF از همان اولین مراحل طراحی، ملاحظات ضروری جهت رسیدن به بالاترین درجه سازگاری با مدل MVVM لحاظ گردیده است. همچنین چنانچه اشاره شد یکی از فعالیتهای گروه طراحی WPF که به موازات پروژه اصلی دنبال شده در قالب یک پروژه مجزا به نام PRISM به همراه مستندات بسیار آموزنده و چندین پروژه نمونه آماده شده، با موفقیت بی نظیر در حال توسعه میباشد. نظر شخصی من این است که پروژه PRISM در حال حاضر مهم ترین و بهترین منبع آموزشی برای فراگیری مدل MVVM در WPF یا Silverlight می باشد. مخصوصا در حوزه برنامه های Web-based و تواناییهای بالقوه Silverlight در این زمینه، انتخاب آن را برای برنامه نویسانی که از میزان تجربه و مهارت بالایی برخوردار می باشند، اجتناب ناپذیر میسازد. به جرات میتوان ادعا نمود که ترکیب فوق العاده و بسیار هماهنگ منطق MVVM با امکانات ذاتی Silverlight در ارائه UI بسیار چشم نواز و قدرتمند ، در حال حاضر بی رقیب بوده و در میان مجموعه تکنولوژی های مایکروسافت از بهترین ها محسوب میشود.