ASP.NET MVC #1

چرا ASP.NET MVC ؟

با وجود فريم ورك پخته‌اي به نام ASP.NET web forms، اولين سؤالي كه حين سوئيچ به ASP.NET MVC مطرح مي‌شود اين است: «براي چي؟». بنابراين تا به اين سؤال پاسخ داده نشود، هر نوع بحث فني در اين مورد بي فايده است.

مزاياي ASP.NET MVC نسبت به ASP.NET web forms

1) سادگي نوشتن آزمون‌هاي واحد
مهم‌ترين دليل استفاده از ASP.NET MVC صرفنظر از تمام دلايل ديگر، بحث طراحي ويژه آن جهت ساده سازي تهيه آزمون‌هاي واحد است. مشكل اصلي نوشتن آزمون‌هاي واحد براي برنامه‌هاي ASP.NET web forms، درگير شدن مستقيم با تمام جزئيات طول عمر يك صفحه است. به علاوه فايل‌هاي code behind هر چند به ظاهر كدهاي منطق يك صفحه را از كدهاي HTML مانند آن جدا مي‌كنند اما در عمل حاوي ارجاعات مستقيمي به تك تك عناصر بصري موجود در صفحه هستند (حس غلط جدا سازي كدها از اجزاي يك فرم). اگر قرار باشد براي اين وب فرم‌ها و صفحات، آزمون واحد بنويسيم بايد علاوه بر شبيه سازي چرخه طول عمر صفحه و همچنين رخدادهاي رسيده، كار وهله سازي تك تك عناصر بصري را نيز عهده دار شويم. اينجا است كه ASP.NET web forms گزينه‌ي مطلوبي براي اين منظور نخواهد بود و اگر نوشتن آزمون واحد براي آن غيرممكن نباشد، به همين دلايل آنچنان مرسوم هم نيست.
البته شايد بپرسيد كه اين مساله چه اهميتي دارد؟ امكان نوشتن ساده‌تر آزمون‌هاي واحد مساوي است با امكان ساده‌تر اعمال تغييرات به يك پروژه بزرگ. تغييرات در پروژه‌هاي بزرگي كه آزمون واحد ندارند واقعا مشكل است. يك قسمت را تغيير مي‌دهيد، 10 قسمت ديگر به هم مي‌ريزند. اينجا است كه مدام بايد به كارفرما گفت: «نه!»، «نميشه!» يا به عبارتي «نمي‌تونم پروژه رو جمع كنم!» چون نمي‌تونم سريع برآورد كنم كه اين تغييرات كدام قسمت‌ها را تحت تاثير قرار مي‌دهند، كجا به هم ريخت. من بايد خودم سريع بتونم مشخص كنم با اين تغيير جديد چه قسمت‌هايي به هم ريخته تا اينكه دو روز بعد زنگ بزنند: «باز جايي رو تغيير دادي، يكجاي ديگر كار نمي‌كنه!»

2) دستيابي به كنترل بيشتر بر روي اجزاي فريم ورك
در طراحي ASP.NET MVC همه‌جا interface ها قابل مشاهد هستند. همين مساله به معناي افزونه پذيري اكثر قطعات تشكيل دهنده ASP.NET MVC است؛ برخلاف ASP.NET web forms. براي مثال تابحال چندين view engine، routing engine و غيره توسط برنامه نويس‌هاي مستقل براي ASP.NET MVC طراحي شده‌اند كه هيچكدام با ASP.NET web forms ميسر نيست. براي مثال از view engine پيش فرض آن خوشتان نمي‌آيد؟ عوضش كنيد! سيستم اعتبار سنجي توكار آن‌را دوست نداريد؟ آن‌را با يك نمونه بهتر تعويض كنيد و الي آخر ...
به علاوه طراحي بر اساس interface ها يك مزيت ديگر را هم به همراه دارد و آن هم ساده سازي mocking (تقليد) آن‌ها است جهت ساده سازي نوشتن آزمون‌هاي واحد.

3) سرعت بيشتر اجرا
ASP.NET MVC يك سري از قابليت‌هاي ذاتي ASP.NET web forms را مانند ViewState حذف كرده است. اگر وب را جستجو كنيد، برنامه نويس‌هاي ASP.NET web forms مدام از اين مساله شكايت دارند و راه‌ حل‌هاي مختلفي را جهت حذف يا فشرده سازي آن ارائه مي‌دهند. ViewState در ابتداي امر جهت شبيه سازي محيط دسكتاپ در وب درنظر گرفته شده بود و مهاجرت ساده‌تر برنامه نويس‌هاي VB6 به وب، اما واقعيت اين است كه اگر يك برنامه نويس ASP.NET web forms به اندازه آن توجهي نداشته باشد، ممكن است حجم آن در يك صفحه پيچيده تا 500 كيلوبايت يا بيشتر هم برسد. همين مساله بر روي سرعت دريافت و اجرا تاثير گذار خواهد بود.

4) كنترل‌هاي ASP.NET web forms آنچنان آش دهن‌سوزي هم نيستند!
خوب، ViewState حذف شده، بنابراين اكثر كنترل‌هاي ASP.NET web forms هم كاربرد آنچناني در ASP.NET MVC نخواهند داشت؛ اما واقعيت اين است كه اكثر اوقات اگر شروع به سفارشي سازي يك كنترل توكار ASP.NET web forms كنيد تا مطابق نيازهاي كاري شما رفتار كند، پس از مدتي به يك كنترل كاملا از نو بازنويسي شده خواهيد رسيد! بنابراين در ابتداي امر تا 80 درصد كار اينطور به نظر مي‌رسد كه به عجب سرعت بالايي در توسعه دست يافته‌ايم، اما هنگاميكه قرار است اين 20 درصد پاياني را پر كنيم، به اين نتيجه خواهيم رسيد كه اين كنترل‌ها با اين وضع ابتدايي كه دارند قابل استفاده نيستند و نياز به دستكاري قابل ملاحظه‌اي دارند تا نيازهاي واقعي كاري را برآورده كنند.

5) كنترل كامل بر روي HTML نهايي توليدي
اگر علاقمند به كار با jQuery باشيد، مدام نياز خواهيد تا با ID كنترل‌ها و عناصر صفحه كار كنيد. پيشتر ASP.NET web forms اين ID را يك طرفه و به صورت مقدار منحصربفردي توليد مي‌كرد كه جهت كار با فريم ورك‌هاي جاوا اسكريپتي عموما مشكل ساز بود. البته ASP.NET web forms در نگارش‌هاي جديد خود مشكل عدم امكان مقدار دهي ClientId سفارشي را براي كنترل‌هاي وب خود برطرف كرده است و اين مورد را مي‌توان دستي هم تنظيم كرد ولي در كل باز هم آنچنان كنترلي رو خروجي HTML نهايي كنترل‌هاي توليدي نيست مگر اينكه مانند مورد چهارم ياد شده يك كنترل را از صفر بازنويسي كنيد!
همچنين اگر باز هم بيشتر با jQuery و ASP.NET web forms كار كرده باشيد مي‌دانيد كه jQuery آنچنان سنخيتي با ViewState و Postback وب فرم‌ها ندارد و همين مساله عموما مشكل‌زا است. علاوه بر آن اخيرا مايكروسافت توسعه ASP.NET Ajax خود را تقريبا در حالت تعليق و واگذار شده به شركت‌هاي ثالث درآورده است و توصيه آن‌ها استفاده از jQuery Ajax است. اينجا است كه مدل ASP.NET MVC سازگاري كاملي را با jQuery Ajax دارد هم از لحاظ نبود ViewState و هم از جنبه‌ي كنترل كامل بر روي markup نهايي توليدي.
يا براي مثال خروجي پيش فرض يك GridView، جدول HTML ايي است كه اين روزها همه‌جا عليه آن صحبت مي‌شود. البته يك سري آداپتور CSS friendly براي اكثر اين كنترل‌ها موجود است و ... باز هم دستكاري بيش از حد كنترل‌هاي پيش فرض جهت رسيدن به خروجي دلخواه. تمام اين‌ها را در ASP.NET MVC مي‌شود با معادل‌هاي بسيار باكيفيت افزونه‌هاي jQuery جايگزين كرد و از همه مهم‌تر چون ViewState و مفاهيمي مانند PostBack حذف شده، استفاده از اين افزونه‌ها مشكل ساز نخواهد بود.

6) استفاده از امكانات جديد زبان‌هاي دات نتي
طراحي اصلي ASP.NET web forms مربوط است به دوران دات نت يك؛ زمانيكه نه Generics وجود داشت، نه LINQ و نه آنچنان مباحث TDD يا استفاده از ORMs متداول بود. براي مثال شايد ايجاد يك strongly typed web form الان كمي دور از ذهن به نظر برسد، زمانيكه اصل آن بر مبناي بكارگيري گسترده datatable و dataset بوده است (با توجه به امكانات زبان‌هاي دات نتي در آن دوران). بنابراين اگر علاقمند هستيد كه اين امكانات جديد را بكاربگيريد، ASP.NET MVC براي استفاده از آن‌ها طراحي شده است!

7) از ASP.NET web forms ساده‌تر است
طراحي ASP.NET MVC بر اساس ايده Convention over configuration است. به اين معنا كه اجزاي آن بر اساس يك سري قرار داد در كنار هم مشغول به كار هستند. مشخص است View بايد كجا باشد، نام كنترلرها چگونه بايد تعيين شوند و قرار داد مرتبط به آن چيست، مدل بايد كجا قرار گيرد، قرار داد پردازش آدرس‌هاي صفحات سايت به چه نحوي است و الي آخر. خلاصه در بدو امر با يك فريم ورك حساب شده كه شما را در مورد نحوه استفاده صحيح از آن راهنمايي مي‌كند، مواجه هستيد.
به همين ترتيب هر پروژه MVC ديگري را هم كه مشاهده كنيد، سريع مي‌توانيد تشخيص دهد قراردادهاي بكارگرفته شده در آن چيست. بنابراين اگر قرار است ASP.NET را امروز شروع كنيد و هيچ سابقه‌اي هم از وب فرم‌ها نداريد، يك راست با ASP.NET MVC شروع كنيد.

8) محدود به پياده سازي مايكروسافت نيست
پياده سازي‌هاي مستقلي هم از ASP.NET MVC توسط اشخاص و گروه‌هاي خارج از مايكروسافت وجود دارد: ^، ^، ^، ^ و ...


و در پايان يكي ديگر از دلايل سوئيچ به ASP.NET MVC ، «ياد گرفتن يك چيز جديد است» يا به عبارتي فرا گرفتن يك روش ديگر براي حل مسايل، هيچگاه ضرري را به همراه نخواهد داشت كه هيچ، بلكه باعث بازتر شدن ميدان ديد نيز خواهد گرديد.


يك ديدگاه ديگر
ASP.NET MVC براي شما مناسب نخواهد بود اگر ...
1) با پلي‌مرفيزم مشكل داريد.
ASP.NET MVC پر است از interfaces، abstract classes، virtual methods و امثال آن. بنابراين اگر تازه كار هستيد، ابتدا بايد مفاهيم شيءگرايي را تكميل كنيد.

2) اگر نمي‌توانيد فريم ورك خودتون رو بر پايه ASP.NET MVC بنا كنيد!
ASP.NET MVC برخلاف وب فرم‌ها به همراه آنچنان تعداد بالايي كنترل و افزونه از پيش مهيا شده نيست. در بدو امر شما فقط يك سري url helper، html helper و ajax helper ساده را خواهيد ديد؛ اين نقطه ضعف ASP.NET MVC نيست. عمدا به اين نحو طراحي شده است. همانطور كه عنوان شد اكثر اجزاي اين فريم ورك قابل تعويض است. بنابراين دست شما را باز گذاشته است تا با پياده سازي اين اينترفيس‌ها، امكانات جديدي را خلق كنيد. البته پس از اين چندين و چند سال كه از ارائه آن مي‌گذرد، به اندازه كافي افزونه براي ASP.NET MVC طراحي شده است كه به هيچ عنوان احساس كمبود نكنيد يا اينكه نيازي هم نداشته باشيد تا آنچنان فريم ورك خاصي را بر پايه ASP.NET MVC تهيه كنيد. براي مثال پروژه MvcContrib موجود است يا شركت telerik يك مجموعه سورس باز كامل مخصوص ASP.NET MVC را ارائه داده است و الي آخر.

3) اگر نمي‌توانيد از كتابخانه‌هاي سورس باز استفاده كنيد.
همانطور كه عنوان شد ASP.NET MVC به همراه كوهي از كنترل‌ها ارائه نشده است. اكثر افزونه‌هاي آن سورس باز هستند و كار با آن‌ها هم دنياي خاص خودش را دارد. چگونه بايد كتابخانه‌هاي مناسب را پيدا كرد، كجا سؤال پرسيد، كجا باگ گزارش داد، چگونه مشاركت كرد و غيره. خلاصه منتظر يك بسته شكيل حاضر و آماده نبايد بود. خود ASP.NET MVC هم تحت مجوز MSPL به صورت سورس باز در دسترس است.


و يك نكته تكميلي
مايكروسافت مدتي است شروع كرده به پرورش و زمزمه ايده «يك ASP.NET واحد». به عبارتي قصد دارند در يكي دو نگارش بعد، اين دو (وب فرم و MVC) را يكي كنند. هم اكنون اگر مطالب وبلاگ‌ها را مطالعه كنيد زيرساخت آن به نام ASP.NET Web API آماده شده است و در مرحله بتا است. نكته جالب اينجا است كه اين Web API امكان تعريف يكپارچه و مستقيم كنترلر‌هاي MVC را در وب فرم‌ها ميسر مي‌كند. ولي باز هم نام آن Controller است يعني جزئي از ASP.NET MVC و كسي مي‌تواند از آن استفاده كند كه با MVC‌ مشكلي نداشته باشد. بنابراين يادگيري MVC هيچ ضرري نخواهد داشت و جاي دوري نخواهد رفت!