1. مهمان گرامی، جهت ارسال پست، دانلود و سایر امکانات ویژه کاربران عضو، ثبت نام کنید.
    بستن اطلاعیه

آموزش ASP.NET MVC

شروع موضوع توسط minaaa ‏16/4/12 در انجمن .Net

  1. minaaa

    کاربر پیشرفته

    تاریخ عضویت:
    ‏9/12/10
    ارسال ها:
    19,773
    تشکر شده:
    6,457
    امتیاز دستاورد:
    113
    [h=1]آموزش ASP.NET MVC - بخش اول[/h]
    [​IMG]​
    چرا 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 هيچ ضرري نخواهد داشت و جاي دوري نخواهد رفت!
    به نقل از dotnettips.info
     
    minaaa, ‏16/4/12
    #1
  2. minaaa

    کاربر پیشرفته

    تاریخ عضویت:
    ‏9/12/10
    ارسال ها:
    19,773
    تشکر شده:
    6,457
    امتیاز دستاورد:
    113
    پاسخ : آموزش ASP.NET MVC

    [h=1]آموزش ASP.NET MVC - بخش دوم[/h]
    [​IMG]​
    MVC‌ چيست و اساس كار آن چگونه است؟

    الگوي MVC در سال‌هاي اول دهه 70 ميلادي در شركت زيراكس توسط خالقين زبان اسمال‌تاك كه جزو اولين زبان‌هاي شيءگرا محسوب مي‌شود، ارائه گرديد. نام MVC از الگوي Model-View-Controller گرفته شده و چندين دهه است كه در صنعت توليد نرم افزار مورد استفاده مي‌باشد. هدف اصلي آن جدا سازي مسئوليت‌هاي اجزاي تشكيل دهنده «لايه نمايشي» برنامه است.
    اين الگو در سال 2004 براي اولين بار در سكويي به نام Rails به كمك زبان روبي جهت ساخت يك فريم ورك وب MVC مورد استفاده قرار گرفت و پس از آن به ساير سكوها مانند جاوا، دات نت (در سال 2007)، PHP و غيره راه يافت.
    تصاويري را از اين تاريخچه در ادامه ملاحظه مي‌كنيد؛ از دكتر Trygve Reenskaug تا شركت زيراكس و معرفي آن در Rails به عنوان اولين فريم ورك وب MVC.


    MVC‌ چيست و اساس كار آن چگونه است؟

    الگوي MVC در سال‌هاي اول دهه 70 ميلادي در شركت زيراكس توسط خالقين زبان اسمال‌تاك كه جزو اولين زبان‌هاي شيءگرا محسوب مي‌شود، ارائه گرديد. نام MVC از الگوي Model-View-Controller گرفته شده و چندين دهه است كه در صنعت توليد نرم افزار مورد استفاده مي‌باشد. هدف اصلي آن جدا سازي مسئوليت‌هاي اجزاي تشكيل دهنده «لايه نمايشي» برنامه است.
    اين الگو در سال 2004 براي اولين بار در سكويي به نام Rails به كمك زبان روبي جهت ساخت يك فريم ورك وب MVC مورد استفاده قرار گرفت و پس از آن به ساير سكوها مانند جاوا، دات نت (در سال 2007)، PHP و غيره راه يافت.
    تصاويري را از اين تاريخچه در ادامه ملاحظه مي‌كنيد؛ از دكتر Trygve Reenskaug تا شركت زيراكس و معرفي آن در Rails به عنوان اولين فريم ورك وب MVC.
    [​IMG]​
    C در MVC معادل Controller است. كنترلر قسمتي است كه كار دريافت ورودي‌هاي دنياي خارج را به عهده دارد؛ مانند پردازش يك درخواست HTTP ورودي.


    [​IMG]​
    زمانيكه كنترلر اين درخواست را دريافت مي‌كند، كار وهله سازي Model را عهده دار خواهد شد و حاوي اطلاعاتي است كه نهايتا در اختيار كاربر قرار خواهد گرفت تا فرآيند پردازش درخواست رسيده را تكميل نمايد. براي مثال اگر كاربري جهت دريافت آخرين اخبار به سايت شما مراجعه كرده است،‌ در اينجا كار تهيه ليست اخبار بر اساس مدل مرتبط به آن صورت خواهد گرفت. بنابراين كنترلرها، پايه اصلي و مدير اركستر الگوي MVC محسوب مي‌شوند.
    در ادامه، كنترلر يك View را جهت نمايش Model انتخاب خواهد كرد. View در الگوي MVC يك شيء ساده است. به آن مي‌توان به شكل يك قالب كه اطلاعاتي را از Model دريافت نموده و سپس آن‌ها را در مكان‌هاي مناسبي در صفحه قرار مي‌دهد، نگاه كرد.
    نتيجه استفاده از اين الگو، ايزوله سازي سه جزء ياد شده از يكديگر است. براي مثال View نمي‌داند و نيازي ندارد كه بداند چگونه بايد از لايه دسترسي به اطلاعات كوئري بگيرد. يا براي مثال كنترلر نيازي ندارد بداند كه چگونه و در كجا بايد خطايي را با رنگي مشخص نمايش دهد. به اين ترتيب انجام تغييرات در لايه رابط كاربري برنامه در طول توسعه كلي سيستم، ساده‌تر خواهد شد.
    همچنين در اينجا بايد اشاره كرد كه اين الگو مشخص نمي‌كند كه از چه نوع فناوري دسترسي به اطلاعاتي بايد استفاده شود. مي‌توان از بانك‌هاي اطلاعاتي، وب سرويس‌ها، صف‌ها و يا هر نوع ديگري از اطلاعات استفاده كرد. به علاوه در اينجا در مورد نحوه طراحي Model نيز قيدي قرار داده نشده است. اين الگو تنها جهت ساخت بهتر و اصولي «رابط كاربري» طراحي شده است و بس.



    تفاوت مهم پردازشي ASP.NET MVC با ASP.NET Web forms

    اگر پيشتر با ASP.NET Web forms كار كرده باشيد اكنون شايد اين سؤال برايتان وجود داشته باشد كه اين سيستم جديد در مقايسه با نمونه قبلي، چگونه درخواست‌ها را پردازش مي‌كند.
    [​IMG]​
    همانطور كه مشاهده مي‌كنيد، در وب فرم‌ها زمانيكه درخواستي دريافت مي‌شود، اين درخواست به يك فايل موجود در سيستم مثلا default.aspx ارسال مي‌گردد. سپس ASP.NET يك كلاس وهله سازي شده معرف آن صفحه را ايجاد كرده و آن‌را اجرا مي‌كند. در اينجا چرخه طول عمر صفحه مانند page_load و غيره رخ خواهد داد. جهت انجام اين وهله سازي، View به فايل code behind خود گره خورده است و جدا سازي خاصي بين اين دو وجود ندارد. منطق صفحه به markup آن كه معادل است با يك فايل فيزيكي بر روي سيستم، كاملا مقيد است. در ادامه، اين پردازش صورت گرفته و HTML نهايي توليدي به مرورگر كاربر ارسال خواهد شد.
    در ASP.NET MVC اين نحوه پردازش تغيير كرده است. در اينجا ابتدا درخواست رسيده به يك كنترلر هدايت مي‌شود و اين كنترلر چيزي نيست جز يك كلاس مجزا و مستقل از هر نوع فايل ASPX ايي در سيستم. سپس اين كنترلر كار پردازش درخواست رسيده را شروع كرده، اطلاعات مورد نياز را جمع آوري و سپس به View ايي كه انتخاب مي‌كند، جهت نمايش نهايي ارسال خواهد كرد. در اينجا View اين اطلاعات را دريافت كرده و نهايتا در اختيار كاربر قرار خواهد داد.



    آشنايي با قرارداد يافتن كنترلرهاي مرتبط

    تا اينجا دريافتيم كه نحوه پردازش درخواست‌ها در ASP.NET MVC بر مبناي كلاس‌ها و متدها است و نه بر مبناي فايل‌هاي فيزيكي موجود در سيستم. اگر درخواستي به سيستم ارسال مي‌شود، در ابتدا، اين درخواست جهت پردازش، به يك متد عمومي موجود در يك كلاس كنترلر هدايت خواهد شد و نه به يك فايل فيزيكي ASPX (برخلاف وب فرم‌ها).
    [​IMG]​
    همانطور كه در تصوير مشاهده مي‌كنيد، در ابتداي پردازش يك درخواست، آدرسي به سيستم ارسال خواهد شد. بر مبناي اين آدرس، نام كنترلر كه در اينجا زير آن خط قرمز كشيده شده است، استخراج مي‌گردد (براي مثال در اينجا نام اين كنترلرProducts است). سپس فريم ورك به دنبال كلاس اين كنترلر خواهد گشت. اگر آن‌را در اسمبلي پروژه بيابد، از آن خواهد خواست تا درخواست رسيده را پردازش كند؛ در غيراينصورت پيغام 404 يا يافت نشد، به كاربر نمايش داده مي‌شود.
    اما فريم ورك چگونه اين كلاس كنترلر درخواستي را پيدا مي‌كند؟
    در زمان اجرا، اسمبلي اصلي پروژه به همراه تمام اسمبلي‌هايي كه به آن ارجاعي دارند جهت يافتن كلاسي با اين مشخصات اسكن خواهند شد:
    1- اين كلاس بايد عمومي باشد.
    2- اين كلاس نبايد abstract باشد (تا بتوان آن‌را به صورت خودكار وهله سازي كرد).
    3- اين كلاس بايد اينترفيس استاندارد IController را پياده سازي كرده باشد.
    4- و نام آن بايد مختوم به كلمه Controller باشد (همان مبحث Convention over configuration يا كار كردن با يك سري قرار داد از پيش تعيين شده).

    براي مثال در اينجا فريم ورك به دنبال كلاسي به نام ProductsController خواهد گشت.
    شايد تعدادي از برنامه نويس‌هاي ASP.NET MVC تصور ‌كنند كه فريم ورك در پوشه‌ي استانداردي به نام Controllers به دنبال اين كلاس خواهد گشت؛ اما در عمل زمانيكه برنامه كامپايل مي‌شود، پوشه‌اي در اين اسمبلي وجود نخواهد داشت و همه چيز از طريق Reflection مديريت خواهد شد.
    به نقل از dotnettips.info
     
    minaaa, ‏16/4/12
    #2
  3. minaaa

    کاربر پیشرفته

    تاریخ عضویت:
    ‏9/12/10
    ارسال ها:
    19,773
    تشکر شده:
    6,457
    امتیاز دستاورد:
    113
    پاسخ : آموزش ASP.NET MVC

    [h=1]آموزش ASP.NET MVC - بخش سوم[/h]
    [​IMG]​
    .NET MVC 3 پس از ارائه Visual Studio 2010، منتشر شد و VS.NET به صورت پيش فرض به همراه ASP.NET MVC 2 است. ساده‌ترين روش نصب ASP.NET MVC 3 بر روي VS 2010 استفاده از برنامه رايگاني است به نام Web Platform Installer. اين برنامه را از اين آدرس مي‌توان دريافت كرد: http://microsoft.com/web/downloads
    پس از دريافت آن حداقل دو راه براي نصب ASP.NET MVC 3 وجود دارد. يا گزينه‌ي نصب ASP.NET MVC 3 Tools Update را انتخاب كنيد و يا سرويس پك يك VS 2010 را از طريق اين برنامه يا جداگانه (بسته كامل و مستقل) دريافت و نصب نمائيد. VS 2010 SP1 نيز به همراه ASP.NET MVC 3 است؛ همچنين IIS Express را كه نسخه ساده شده IIS 7.5 مخصوص توسعه دهنده‌ها است، مي‌توان با اين نگارش يكپارچه كرد.


    تهيه پيش‌نيازهاي شروع به كار با ASP.NET MVC

    در زمان نگارش اين مطلب، نگارش نهايي ASP.NET MVC 3 در دسترس است و همچنين نگارش بتاي 4 آن نيز قابل دريافت و نصب مي‌باشد. بنابراين فعلا اساس را بر مبناي نگارشي قرار خواهيم داد كه در محيط كاري قابل استفاده باشد.
    ASP.NET MVC 3 پس از ارائه Visual Studio 2010، منتشر شد و VS.NET به صورت پيش فرض به همراه ASP.NET MVC 2 است. ساده‌ترين روش نصب ASP.NET MVC 3 بر روي VS 2010 استفاده از برنامه رايگاني است به نام Web Platform Installer. اين برنامه را از اين آدرس مي‌توان دريافت كرد:     http://microsoft.com/web/downloads
    پس از دريافت آن حداقل دو راه براي نصب ASP.NET MVC 3 وجود دارد. يا گزينه‌ي نصب ASP.NET MVC 3 Tools Update را انتخاب كنيد و يا سرويس پك يك VS 2010 را از طريق اين برنامه يا جداگانه (بسته كامل و مستقل) دريافت و نصب نمائيد. VS 2010 SP1 نيز به همراه ASP.NET MVC 3 است؛ همچنين IIS Express را كه نسخه ساده شده IIS 7.5 مخصوص توسعه دهنده‌ها است، مي‌توان با اين نگارش يكپارچه كرد.
    [​IMG]​
    بنابراين به صورت خلاصه بهترين كار اين است كه سرويس پك يك VS 2010 را يكبار نصب نمائيد. اگر اين نصب از طريق برنامه Web Platform Installer باشد، به صورت خودكار IIS Express را هم انتخاب و نصب خواهد كرد. اگر فقط SP1 را به صورت مستقل دريافت كرده‌ايد، حاوي IIS Express نيست و بايد جداگانه آن‌را دريافت و نصب نمائيد (^). البته نصب IIS Express در اينجا يك گزينه اختياري است و الزامي نيست.



    مروري بر ساختار يك پروژه ASP.NET MVC

    پس از نصب پيش نيازها، امكان انتخاب يك پروژه وب ASP.NET MVC 3 در VS 2010 ميسر خواهد شد:
    [​IMG]​
    در اينجا گزينه‌ي ASP.NET MVC 3 Web Application را انتخاب مي‌كنيم. در صفحه بعدي كه ظاهر مي‌شود:
    [​IMG]​
    حالت Internet Application به همراه يك سري مدل و كنترلر از پيش نوشته شده جهت مديريت ورود به سايت و ثبت نام در سايت است و حالت Empty تنها به همراه ساختار پيش فرض پوشه‌هاي يك پروژه ASP.NET MVC است.
    فعلا جهت توضيحات اوليه بيشتر، گزينه‌ي Internet Application و نوع View Engine را هم ASPX انتخاب مي‌كنيم. كار View Engine، رندر يك View به شكل HTML و ارائه نهايي اطلاعات آن به كاربر است. اين نوع‌هاي متفاوت هم فقط در Syntax تفاوت دارند (به آن templating language هم گفته مي‌شود). نوع ASPX همان Syntax متداول قديمي ASP.NET را تداعي مي‌كند و نوع Razor به صورت اختصاصي براي ASP.NET MVC تهيه شده است.
    بايد در نظر داشت كه گزينه مرجح از نگارش 3 به بعد، Razor است (البته اين هم سليقه‌اي است. اگر هيچكدام از اين دو را هم نخواهيد استفاده كنيد مشكلي نيست! مي‌شود كلا آن را عوض كرد). هدفم هم از انتخاب ASPX نمايش يك سري ريزه كاري است كه شايد براي برنامه نويس‌هاي ASP.NET Web forms جالب باشد. اين موارد را در حالت انتخاب Razor به اين وضوح مشاهده نخواهيد كرد و محيط خيلي ساده شده است.
    [​IMG]​
    همانطور كه ملاحظه مي‌كنيد اين فريم ورك يك سري پوشه پيش فرض را توصيه مي‌كند. بديهي است كه ضرورتي ندارد تا پوشه Models يا پوشه Controllers حتما در همين پروژه قرار داشته باشند؛ چون زمانيكه پروژه كامپايل شد، محل اين پوشه بندي‌ها آنچنان اهميتي ندارد.
    نكته جالب در اين تصوير، فايل Site.Master است. بله، اين فايل شبيه به همان فايل master page موجود در ASP.NET Web form است كه قالب كلي سايت را به همراه داشته و ساير صفحات، قالب خود را از آن به ارث مي‌برند. حتي ويژگي runat=server هم به وضوح در اين فايل، در چندين جاي آن قابل مشاهده است. تنها تفاوت آن نداشتن فايل code behind است. asp:ContentPlaceHolder نيز در آن تعريف شده است. خلاصه اين محيط جديد به معناي دور ريختن تمام آنچيزي كه در Web forms وجود دارد نيست. براي نمونه اگر فايل ChangePassword.aspx موجود در پوشه Account را باز كنيد، باز هم همان asp:Content معروف به همراه ويژگي runat=server قابل مشاهده است. براي مثال اين محتواي صفحه Error.aspx پيش فرض آن است:

    <%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<System.Web.Mvc.HandleErrorInfo>" %> <asp:Content ID="errorTitle" ContentPlaceHolderID="TitleContent" runat="server"> Error </asp:Content> <asp:Content ID="errorContent" ContentPlaceHolderID="MainContent" runat="server"> <h2> Sorry, an error occurred while processing your request. </h2> </asp:Content>

    اگر از قسمت Inherits آن صرفنظر كنيم، «هيچ» تفاوتي با ASP.NET Web forms ندارد؛ علت هم به اين بر مي‌گردد كه موتوري كه Web forms و MVC از آن استفاده مي‌كنند، يكي است. هر دو بر فراز موتور ASP.NET معنا پيدا خواهند كرد.


    قرار دادهاي پوشه‌هاي پيش فرض يك پروژه ASP.NET MVC

    • پوشه Controllers حاوي كلاس‌هاي كنترلري است كه درخواست‌هاي رسيده را مديريت مي‌كنند.
    • پوشه Models حاوي كلاس‌هايي است كه اشياء تجاري و همچنين كار با اطلاعات را تعريف و مديريت مي‌كنند.
    • در پوشه Views، فايل‌هاي قالب‌هاي رابط كاربري كه مسئول ارائه خروجي به كاربر هستند قرار مي‌گيرند. همچنين مطابق قرارداد ديگري، اگر نام كنترلر ما مثلا ProductController باشد (با توجه به اينكه نام كلاس آن هم مطابق قرارداد، مختوم به كلمه Controller است)، فايل‌هاي Viewهاي مرتبط با آن در پوشه Views/Product قرار خواهند گرفت.
    • در پوشه Scripts،‌ فايل‌هاي جاوا اسكريپت مورد استفاده در سايت قرار خواهند گرفت.
    • پوشه Content محل قرارگيري فايل‌هاي CSS و تصاوير است.
    • پوشه App_Data جايي است كه فايل‌هايي با قابليت read/write در آن قرار مي‌گيرند (و بايد دقت داشت كه فقط همينجا هم بايد قرار گيرند و گرنه اين نوشتن‌ها در مكان‌هاي متفرقه، ممكن است سبب ري استارت شدن برنامه شوند
    به نقل از dotnettips.info
     
    minaaa, ‏16/4/12
    #3