معرفی کتاب Professional ASP .NET MVC 4 ویرایش چهارم، انتشارات APress

      کتاب Professional ASP .NET MVC 4 را می توان به جرأت یکی از بهترین ها در زمینه آشنایی حرفه ای با تکنولوژی MVC معرفی نمود.
این کتاب مشتمل بر 738 صفحه و شامل دو قسمت (Part) می باشد که مجموعا در 26 فصل جداگانه تدوین شده است. آدام فریمن (Adam Freeman) نیازی به معرفی ندارد و سابقه درخشان او مخصوصا در اتشارات APress خود گویای این نکته است که تیراژ بسیار بالای آثار او به هیچ وجه اتفاقی نیست . تسلط عمیق و نگاه دقیق و ریز بینانه این برنامه نویس نویسنده از همان ابتدا خواننده را مجاب میکند که باید سطر به سطر توضیحات او را دقیقا مطالعه کرده و مخصوصا در مورد مثالها با صرف وقت مناسب نکات مورد نظر نویسنده را تشخیص دهد.

 

سطح کتاب چنانچه از نام آن نیز مشخص است کاملا حرفه ای بوده و مخصوصا از آغاز بخش دوم، که ابتدای فصل 12 نیز محسوب میشود، بوضوح سطح مطالب افزایش چشمگیری داشته و بعد از تشریح مراحل طراحی و تدوین یک Application نمونه ،(که در قسمت اول انجام شده) نویسنده ظرافت های منحصر بفرد این تکنولوژی را با دقت توصیف نموده و با مثالهای بسیار مهم، خواننده را با تکنیکهای آن آشنا می نماید .

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

لینک مستقیم دانلود کتاب :
فرمت PDF ، ویرایش چهارم
حجم فایل: 24 مگابایت

http://it-ebooks.info/book/1617/

درباره MVC

هنگامی که در یک ارزیابی شخصی، حداقل از نظر خودم متوجه شدم که هر یک از اجزای یک پروژه Default از نوع MVC در Visual Studio 2012 و بالاتر، چه نقشی دارند و چه کاری انجام میدهند و در نهایت چه ارتباطی بین اجزا یک پروژه (در همان ابتدای ایجاد پروژه و بدون اضافه کردن یک سطر کد اضافه) وجود دارد، باید اعتراف کنم که اشتباها، جسارت توضیح در مورد این مطلب را پیدا کردم و سعی کردم مطالبی با عنوان کالبد شکافی یک پروژه Default در MVC بنویسم.در ادامه بر اساس فید بک هایی که دریافت کردم، متوجه شدم مشکلاتی وجود دارد و یا حداقل نتیجه، با چیزی که من تصور میکردم بسیار متفاوت است.
به عبارت ساده تر به نظرم رسید از دو حال خارج نیست. یا درک من از موضوع درست نبوده و نیست و یا بیان من با اشکالاتی همراه بوده که موضوع نه تنها ساده تر نشد بلکه پیچیده تر و درک آن با مشکلات بیشتری همراه شد.
نکته ای که باید به آن توجه مخصوصی داشت این است که اصولا MVC بر خلاف ASP .NET Web Form از قواعد بسیار منظمی پیروی میکند که نظیر آن را میتوان در کاربرد معماری MVVM در WPF و مخصوصا Silverlight مشاهده کرد. در اینجا بر خلاف گذشته اولا برنامه نویس اجازه استفاده از سلیقه های شخصی (نه به مفهوم محدود کردن برنامه نویس و سلب ابتکار عمل) را به هیچ وجه نداشته و ثانیا آشنایی مناسب با برنامه نویسی شئ گرا (OOP) از پیش نیازهای اساسی کار با این تکنولوژی منحصر بفرد می باشد . مضافا اینکه در یک سناریوی واقعی و در یک Web-based Application منطبق با مقیاسها و معیارهای امروز، نیاز مبرمی به تلفیق با Client-side Programming و به طور مشخص استفاده از کتابخانه های غنی JQuery وجود دارد. همچنین باید استفاده از AJAX و همچنین Asynchronous Programming و بهره گیری از Real Time Application Programming را با استفاده از کتابخانه هایی نظیر SignalR مورد توجه بیشتری قرار داد . هر چند این موارد اخیر در یک پروژه Default وجود ندارند و نیازی هم به وجود آنها در مقطع آغاز یک برنامه، نمی باشد.
در هر حال به نظرم رسید با یک تجدید نظر مجدد در نحوه دیدگاه شخصی خودم و البته این بار با اتکا به مقایسه تکنیک های موجود در MVC و مخصوصا با تکنیک های نظیر در ASP .NET Web Form رویکرد متفاوتی نسبت به این موضوع داشته و با نگاه متفاوتی این کار را مجددا آغاز کنم.
در مجموع با توجه به این واقعیت مهم که هم اکنون تکنولوژی برگزیده، جدید و توصیه شده Microsoft در زمینه تولید برنامه های مبتنی بر وب، MVC می باشد، با اشتیاق بسیار مایل هستم سمت و سوی مطالبی که در این گروه به بحث گذاشته میشود، حول و حوش موضوع MVC و مسائل مرتبط بوده و در راستای رسیدن به این هدف، محیط مناسبی برای تبادل نظر و آشنایی با ایده ها و تکنیک های موجود در این زمینه فراهم شود .
 

کالبد شکافی Template پیش فرض یک پروژه MVC (نسخه های 4 و 5) - قسمت سوم

یکی از ارکان اصلی MVC و حتی MVVM توجه به این نکته بسیار مهم است که هیچ ارتباط مستقیم (Reference) و وابستگی (Dependency) بین Model و View وجود نداشته باشد. از سوی دیگر همه ما می دانیم که یکی از نیازهای اصلی در یک برنامه تبادل اطلاعات بین UI و Data source می باشد که وظیفه انجام این ارتباط در MVVM به عهده ViewModel و در MVC به عهده Controller است .
به طور کلی در MVC سه مکانیسم برای ارتباط Controller با View جهت تامین اطلاعات مورد نیاز در View پیش بینی شده است .

روش اول استفاده از ViewData

از دیدگاه ساختمان داده، ViewData یک Dictionary تلقی میشود و چنانچه از قبل میدانیم Dictionary دارای ساختاری است که با استفاده از دو جزء کلید و مقدار (Key Value Pair) امکان دستیابی به این ساختار میسر می باشد . به طور مشخص با تعیین یک کلید (Key) دلخواه مقادیر مورد نظر خودمان را در Dictionary ذخیره کرده و یا بازیابی می کنیم.

public ActionResult ShowError()
{
ViewData["ErrorCode"] = 12345;
ViewData["ErrorDescription"] = "Something bad happened";
ViewData["ErrorDate"] = DateTime.Now;
ViewData["Exception"] = new Exception();
return View();
}

در مثال ارائه شده با تعیین کلیدهای ErrorCode و ErrorDescription و ٍErrorDate و Exception به ترتیب مقادیر 12345 و Something bad happened و DateTime.Now و یک نمونه از کلاس Exception در ViewData قرار گرفته است . بر اساس همین مثال میتوان نتیجه گرفت که امکان قرار دادن هر نوع داده دلخواه ، شامل انواع پایه ساده (Primitive Types) تا انواع داده های پیچیده تر (Complex Types) در ViewData میسر می باشد . همچنین در مثال فوق واضح است که با توجه به اینکه با استفاده از return View() ، صریحا نام View ذکر نشده است، چنانچه قبلا اشاره شد، Controller اطلاعات موجود در ViewData را به یک View هم نام با action یعنی ShowError (فایل ShowError.cshtml) ارسال خواهد کرد. همچنین در مورد محل پیش فرض این فایل قبلا توضیحاتی ارائه شده است .
در Viewی مذکور و با استفاده از موتور Razor دسترسی به اطلاعات ارسال شده به View میسر خواهد بود .

<h1>An error was found</h1>
<h2>Error Code: @ViewBag.ErrorCode</h2>
<h2>@ViewBag.ErrorDescription</h2>

روش دوم استفاده از ViewBag

این روش از بسیاری از جهات با روش قبلی مشابه می باشد و تنها تفاوت در اینجاست که در ViewBag از ویژگی خواص پویا (Dynamic Property) که در C# 4.0 معرفی شد استفاده شده است . لطفا به مثال ساده ای در این زمینه توجه کنید:

public ActionResult ShowError()
{
ViewBag.ErrorCode = 12345;
ViewBag.ErrorDescription = "Something bad happened";
ViewBag.Exception = new Exception();
return View();
}

در این صورت روش دسترسی به داده های موجود در ViewBag از View به صورت زیر خواهد بود :

 

<h1>An error was found</h1>
<h2>Error Code: @ViewBag.ErrorCode</h2>
<h2>@ViewBag.ErrorDescription</h2>

جالب است بدانیم که حتی در هنگام استفاده از ViewBag عملا از ViewData استفاده میشود که در حقیقت از یک Dictionary واحد برای ارسال اطلاعات از Controller به View استفاده خواهد شد. در اینجا ممکن است این سوال مطرح شود که بر اساس مطلبی که عنوان شد آیا استفاده از ViewBag.ErrorCode = 12345; و در ادامه دستیابی به این اطلاعات در View به صورت <h2>@ViewData["ErrorCode"]</h2> مجاز می باشد ؟
پاسخ این سوال مثبت است و البته واضح است که لزومی به استفاده از این روش نیست و تا زمانیکه نام کلید دارای کاراکتر های مجاز و مخصوصا فاقد Space باشد مورد مذکور معتبر خواهد بود .
یک نکته بسیار مهم در هنگام استفاده از ViewData یا ViewBag این است که به محض آنکه View میزبان اطلاعات موجود در یکی از این دو ساختار Dictionary را Render نماید ، دسترسی مجدد به این Dictionary مجاز نخواهد بود . در یک سناریوی ساده تصور کنید که بعد از یک بار Render کردن اطلاعات Dictionary با استفاده از یک RedirectToAction ، مسیر پردازش به یک action دیگر (که نام آن در پارامتر ذکر خواهد شد) هدایت شود . در این صورت واضح است که یک کد 302 به Browser ارسال میشود که از سوی Browser ، اجبار به Redirect به یک مقصد جدید تلقی و تفسیر خواهد شد . در این صورت محتویات Dictionary (منظور ViewData یا ViewBag) به طور کامل Reset شده و دستیابی به این اطلاعات در View جدید به هیچ وجه میسر نخواهد بود . در صورت برخورد با سناریوی مشابه (یعنی نیاز به حفظ موقت اطلاعات تقریبا مشابه با تکنیک استفاده از ViewState در ASP .NET Web Form) توصیه شده که از ساختار TempData که اطلاعات خود را در Session ذخیره می نماید استفاده شود .

روش سوم استفاده از مفهوم Strongly Typed View:

با وجود انعطاف و سادگی دو روش مذکور در بسیاری از سناریو ها امکان استفاده از ViewData و ViewBag میسر نیست و بر اساس توضیحاتی که ارائه شد، به نظر میرسد که استفاده از این دو با محدودیت هایی روبرو می باشد ...

 ... ادامه دارد
 

کالبد شکافی Template پیش فرض یک پروژه MVC (نسخه های 4 و 5) - قسمت دوم

مطابق با ترمینولوژی MVC ، کلاس Controller نقش Dispatcher و توزیع کننده پردازش را با استفاده از متدهای Public خود که action نامیده میشوند، به عهده دارد. در بهترین حالت Controller موظف است که اطلاعات مورد نیاز برنامه را با استفاده از فراخوانی متد های کلاس Model یا شکل مناسب تر آن یعنی ViewModel آماده نموده و آنها را به منظور ایجاد یک خروجی قابل درک توسط انسان به یک View مشخص هدایت نموده تا View آنها را Render نموده و نمایش دهد .
جالب است بدانید که کل ادامه مطلب در حقیقت توضیح وضعیت های متفاوتی است که در پاراگراف قبل به صورت بسیار کلی ذکر شد . در حقیقت هدف من این است که Controller را معرفی نموده حالت های مختلف در متدهای action و تنوعی که در بحث انتخاب View وجود دارد را تشریح نموده و روشهای تبادل اطلاعات Controller و View را بررسی کنم.
اما با بررسی متد نمونه Index در کنترلر Home متوجه خواهیم شد که با توجه به آنچه در این متد مشاهده میکنیم :

public ActionResult Index()
{
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

return View();
}

نوع خروجی متد Index از نوع ActionResult تعیین شده است که کلاس جد انواع متعدد View هایی است که در مورد آنها صحبت خواهیم کرد.
همچنین وجود View() به عنوان مقدار خروجی به طور مشخص ذکر نمیکند که کدام View برای عملیات Rendering در Browser تعیین شده است . رایج ترین شکل استفاده از View حالتی است که در آن، نام View در قالب پارامتر، صریحا ذکر شده و چنانچه در ادامه خواهیم دید حتی نوع اطلاعاتی که به آن Import میشود می تواند به عنوان پارامتر دوم (در قالب مفهوم Model) مشخص شود .
برای شروع پیشنهاد میکنم یک پروژه Internet در MVC 4 ایجاد نمایید . سپس در فولدر Controller کلاس HomeController را باز نموده و متدی به نام NoView به صورت زیر به این کلاس اضافه نمایید. بعد از اضافه کردن این متد کلاس زیر شبیه به کد زیر خواهد بود :

public class HomeController : Controller
{
public ActionResult Index()
{
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

return View();
}

public ActionResult About()
{
ViewBag.Message = "Your app description page.";
return View();
}
public string NoView()
{
return "What's going on?";
}
public ActionResult Contact()
{
ViewBag.Message = "Your contact page.";

return View();
}
}

 

در ادامه برای تکمیل این مثال در فولدر Views/Shared فایل _Layout.cshtml را باز نموده و محتویات داخل <ul id="menu"> را به صورت زیر تغییر دهید . در حقیقت تنها یک سطر به محتویات تگ ul اضافه نموده ایم که نتیجه مطابق با وضعیت زیر خواهد بود :

<ul id="menu">
<li>@Html.ActionLink("Home", "Index", "Home")</li>
<li>@Html.ActionLink("About", "About", "Home")</li>
<li>@Html.ActionLink("Contact", "Contact", "Home")</li>
<li>@Html.ActionLink("No View", "NoView", "Home")</li>
</ul>

 

نتیجه این عملیات این است که ما ابتدا یک action بسیار ساده به نام NoView به کنترلر پیش فرض خودمان یعنی HomeController اضافه می کنیم. در MVC پسوند Controller باید مطابق با یک قاعده (که وحی منزل نیست و قابل تغییر است) همیشه به کلاس Controller ما اضافه شود . به عنوان مثال کنترلر Home به صورت کلاس HomeController ایجاد میشود ولی در هنگام رجوع به آن از نام اصلی یعنی Home استفاده می کنیم .
ما سپس در _Layout.cshtml با استفاده از متد Helper بسیار مهمی به نام ActionLink یک لینک استاندارد با عبارت No View (پارامتر اول) به متد action تازه ایجاد شده خود یعنی NoView (پارامتر دوم) در کنترلر Home (پارامتر سوم) ایجاد کردیم. نتیجه این کار را می توان با اجرای مجدد پروژه، ملاحظه کرد .
اما هدف من از این مثال این است که:
در ارزش هر قطعه ای گویند هر نوعی سخن
من خود به چشم خویشتن دیدم که کنترلر مهم تر است.!!!!:)

در منابع مختلفی که توسط نویسندگان و برنامه نویسان خبره مطرح شده، گاهی مشاهده می کنیم که مقایسه ای در مورد اهمیت هر یک از اجزای Model و View و Controller انجام شده است.
در اینجا شاید ورود به این بحث که اهمیت و ارزش وزنی کدامیک از این اجزا در یک پروژه MVC مهمتر می باشد ، فایده ای نداشته باشد ولی همین مثال ساده ثابت میکند که Controller ما قادر است به طور کاملا مستقل و بدون نیاز به View و Model با استفاده از این action جدید خروجی هر چند ساده و بی اهمیتی را به Browser ارسال کند .
به طور دقیق تر در اینجا عبارت Whats Going On مستقیما و بدون نیاز به View به Response.Stream ارسال میشود که بدون هیچ فرمت خاصی در Browser ظاهر میشود .
چنانچه قبلا هم اشاره شد در مورد action ی که با نام Index در پروژه پیش فرض وجود دارد مشخصا از یک View برای ارسال خروجی و Rendering آن در Browser استفاده شده است اما در متد Index نام این View صریحا ذکر نشده است .
در این حالت MVC به صورت پیش فرض جستجویی در فولدر Views/Home یا Views/Shared به دنبال یک View هم نام با action مذکور انجام داده و در صورت موفقیت آمیز بودن این جستجو، View یافت شده برای ارسال خروجی نهایی انتخاب میشود.
در اینجا این شرط محقق شده است . یعنی با ملاحظه در داخل فولدر Views/Home مشاهده میکنیم که index.cshtml وجود دارد که از دیدگاه MVC یک View ایجاد شده با استفاده از Razor می باشد .
Razor نیز از دیدگاه MVC یک ViewEngine یا موتور ارائه View می باشد که در MVC 3 معرفی شد و از Syntax بسیار ساده ای برخوردار است . کماکان ViewEngine سنتی Asp .NET یعنی aspx در پروژه های MVC قابل استفاده است اما به دلیل سادگی و مقبولیت Razor استفاده از Razor به جای aspx در اغلب منابع توصیه شده است . در Razor ترکیب متجانسی از کد سی شارپ و دستورات HTML را مشاهده خواهیم کرد که در این صورت پسوند چنین فایلهایی cshtml خواهد بود . علاقمندان به VB همچنان به دلیل ارادت مالیخولیایی بیل گیتس به Visual Basic امکان استفاده از vb در Razor را دارند که در این صورت نتیجه فایلهایی با پسوند vbhtml را شاهد خواهیم بود .
از شما چه پنهان من هیچ تعجب نخواهم کرد اگر در آینده ای نزدیک ،Xaml به عنوان یک View Engine مستقل در MVC معرفی و قابل استفاده باشد .
در اینجا لازم به تذکر است که در هنگام انتخاب نوع View به عنوان خروجی متدهای action در Controller ما از طیف متنوعی از انتخاب ها روبرو هستیم که هر یک در موارد خاصی کابرد داشته و استفاده از آنها در MVC رایج می باشد. از مهمترین آنها می توان به موارد زیر اشاره کرد:
ViewResult که رایج ترین و پر استفاده ترین انتخاب در این مورد تلقی میشود و از آنجاییکه ViewResult یکی از کلاسهای منشعب از ActionResult می باشد، قادر است با ارسال View به عنوان خروجی متد action امکان انتخاب View پیش فرض را فراهم نماید. در بیشتر مواقع با استفاده از یک پارامتر نام View مورد نظر در هنگام ارسال View به خروجی ذکر میشود . مثلا ارسال View(“ThatOne”) معادل با انتخاب یک View به نام ThatOne می باشد که در فولدر View با نام ThatOne.cshtml وجود دارد .
PartialViewResult : این کلاس هم مستقیما از ActionResult منشعب شده و برای انتخاب یک Partial View به عنوان مسئول Render کردن بخش یا قسمت مشخصی از یک View بزرگتر کاربرد دارد . برای درک بهتر این مفهوم می توان آن را با MasterPage و Content در ASP .NET Web Form مقایسه کرد. جاییکه Content ها وظیفه Render نمودن قسمت های از پیش تعیین شده MasterPage را بر عهده داشتند .
FileResult که کاربرد آن در زمانیست که نیاز به دانلود مستقیم یک فایل وجود داشته باشد . همچنین از این کلاس به عنوان خروجی یک متد action در مواقعی که قصد نمایش Dynamic تصاویر را داشته باشیم میتوان استفاده نمود .
HttpUnauthorizedResult: که همانطوریکه از نام آن مشخص است برای ارسال کد 401 به Browser استفاده میشود که به معنی Not Authorize بوده و به طور معمول منجر به Redirect شدن درخواست به سمت Page یا صفحه Login خواهد شد که پروسه های Authentication و Authorization انجام شوند.
HttpStatusCodeResult که مشخصا برای ارسال کد های رایج Http به Browser مورد استفاده قرار میگیرد. به عنوان مثال از آن می توان برای ارسال کد 404 به عنوان Page Not Found استفاده نمود .
JsonResult با توجه به شهرت و کاربردهای متنوع فرمت Javascript Object Notation ، بخصوص در وب سرویس ها پیش بینی شده و استفاده میشود .
بعد از یک مرور اجمالی در انتخابهای موجود اینک وقت آن رسیده که جزییات بیشتری را در View بررسی کرده و آنها را بر اساس کاربردهای متنوعی که دارند طبقه بندی کنیم . برای انجام این کار دوباره به قالب استاندارد پروژه بازگشته و توصیه میکنم به محتویات فایل _Layout.cshtml در فولدر Views/Shared با دقت بیشتری نگاه کنید .
نقش _Layout.cshtml بسیار شبیه به نقش MasterPage در ASP .NET Web Form می باشد. معنی دقیق این گفته این است که این فایل (یا مفهوم) معمولا برای تامین اطلاعات قسمت های تکراری در یک Page مثل Header و Logo و Footer و منو های اصلی برنامه کاربرد دارد. این یک روش ایده آل برای انجام این کار و پرهیز از تکرار این قسمتها در همه View های تخصصی برنامه است .
در داخل این فایل مخصوصا فراخوانی @RenderSection("featured", required: false) و @RenderBody() از اهمیت بیشتری برخوردار هستند .
مفهوم Section یک مفهوم نوظهور و ویژه در MVC می باشد که البته هیچ ارتباطی با تگ Sectin در HTML5 ندارد .
فراخوانی RenderSection در این فایل با استفاده از یک پارامت،ر به این معنی می باشد که Layout اصلی Page یک Section و قسمت ویژه ای به نام featured را مشخص نموده که View مسئولیت Render کردن محتویات آن Section را به عهده میگیرد . در صورت استفاده از یک پارامتر در این متد انجام این وظیفه به صورت اجباری به View محول میشود.
در صورت استفاده از پارامتر دوم که نوع آن bool می باشد می توان انجام این عمل را با ارائه مقدار false اختیاری نمود . در صورت عدم ذکر پارامتر دوم مقدار پیش فرض true بوده و معنای آن این است که View موظف است به صورت اجباری یک Section با نام تعیین شده در پارامتر اول پیش بینی نماید .
خود View نیز می تواند قبل از اقدام به تعریف یک Section ابتدا با استفاده از IsSectionDefined که پارامتری از نوع String دریافت میکند از وجود یا عدم وجود این Section مطمئن بشود. پارامتر IsSectionDefined در حقیقت نام Section می باشد.
در داخل View (مثلا در Index.cshtml) ملاحظه خواهیم کرد که ویوی Index اطلاعات مشخصی را برای نمایش در Section رزرو شده به صورت زیر تدارک دیده است :

@section featured {
<section class="featured">
<div class="content-wrapper">
<hgroup class="title">
<h1>@ViewBag.Title.</h1>
<h2>@ViewBag.Message</h2>
</hgroup>
<p>
To learn more about ASP.NET MVC visit
<a href="http://asp.net/mvc" title="ASP.NET MVC Website">http://asp.net/mvc</a>.
The page features <mark>videos, tutorials, and samples</mark> to help you get the most from ASP.NET MVC.
If you have any questions about ASP.NET MVC visit
<a href="http://forums.asp.net/1146.aspx/1?MVC" title="ASP.NET MVC Forum">our forums</a>.
</p>
</div>
</section>
}

همچنین توجه به این نکته ضروریست که یک View می تواند صریحا با ذکر

@{
Layout = null;
{

به صورت مستقل (بدون نیاز به Layout) وظیفه ارسال خروجی به Browser را تقبل نماید . در شکل دیگری از این دستور ، View می تواند یک Layout متفاوت با Layout پیش فرض را به عنوان Layout وابسته خود انتخاب نماید و در نهایت اینکه اگر مقدار null در Layout (حالت اول) ذکر نشود MVC با مراجعه به _ViewStart.cshtml نام و جایگاه Layout پیش فرض را مشخص نموده و از آن به عنوان Layout مورد نظر View استفاده خواهد کرد .
پس انتخابها کاملا روشن و واضح می باشند و نکته مهم در اینجا توجه به رابطه بین یک View و Layout همچنین امکان استفاده از Partial View و Section هاست که باز در مقایسه با ASP .NET Web Form به صورت Nested Master Page و یا حتی شبیه به مفهوم User Control از آنها استفاده نمود .
در انتهای این قسمت باید اشاره کنم که RenderBody در حقیقت نوع خاصی از RenderSection است که محتویات و اطلاعات مشخص شده در View را که در هیچ Section خاصی قرار ندارند ، انتخاب نموده و در محل مشخص شده در فراخوانی RenderBody نمایش داده و یا به طور دقیق تر Render میکند . در برخی از منابع از آن به عنوان Unnamed Section یا Section بدون نام، اسم برده شده است .
در قسمت بعد، به سه مکانیسم مشخص و تعریف شده MVC برای تبادل اطلاعات بین Controller و View اشاره خواهم کرد و مثالهایی در این باره بررسی خواهیم نمود تا زمینه مساعدی برای معرفی و آشنایی با Model و شکل تخصصی تر آن یعنی ViewModel فراهم شود.

 

کالبد شکافی Template پیش فرض یک پروژه MVC (نسخه های 4 و 5) - قسمت اول

مدت نسبتا زیادی است که ذهن من مشغول جزییات این مطلب بوده و متاسفانه به دلایل زیادی امکان پرداختن به آن میسر نشد.
در این فرصت، به بهانه بررسی ساختار پیش فرض یک پروژه ASP .NET MVC سعی خواهم کرد که نقش اجزای مختلف این پروژه را مشخص کرده و با توجه به بضاعت اندک خود، در مورد ارتباط این اجزا توضیحاتی را تقدیم علاقمندان نمایم. پیشاپیش از توجه دوستان و همکاران محترم سپاسگذارم.

به منظور کالبد شکافی یک پروژه ساده MVC و بررسی ارتباط بین اجزای مختلف موجود در Template پیش فرض این پروژه ها به نظر میرسد که توجه به نقش و عملکرد فایل Global.asax به عنوان نقطه شروع این بررسی ، بسیار مفید و آموزنده می باشد.
در واقع فایل Global.asax که به نام ASP .NET Application File نیز شناخته میشود از همان ابتدای تولد تکنولوژی Active Server Page که امروزه به نام ASP کلاسیک شناخته میشود به صورت فایلی با نام Global.asa و بعدها در سال 2003 با ظهور تکنولوژی ASP .NET Web Form به صورت Global.asax به عنوان یک ویژگی Optional و اختیاری به همراه پروژه های ASP .NET مورد استفاده قرار گرفته است. قبل از توضیحاتی در مورد نقش این فایل لازم به ذکر است که تقریبا مقارن با معرفی .NET Framework 3.5 مایکروسافت در ی: اقدام غافلگیرانه به طور کلی معماری Internet Information Server را تغییر داده و با معرفی Integrated Mode در IIS عملا در ساده ترین شکل ممکن این امکان را فراهم کرد که برنامه نویسان نرم افزارهای کاربردی وب با استفاده از رویدادها و Event های تدارک دیده شده در Global.asax و یا در سطوح بالاتر با ایجاد Module های اختصاصی در مراحل مختلف پردازش IIS نظارت و یا در صورت نیاز دخالت نمایند.
خود تکنولوژی MVC محصوصل چنین نگرش متفاوتی میباشد که امکان تغییرات بنیادی در معماری برنامه های مبتنی بر وب را پدید آورد . موضوع رویدادها و Stage های متعددی که در طول مسیر پردازش IIS وجود دارد (این مسیر معمولا به اختصار IIS Processing Pipeline نامیده می شود) موضوع بسیار جالبی برای برنامه نویسانی است که نیاز به کنترل بیشتر در برنامه های مبتنی بر وب (به عنوان مثال ایجاد ماژول های سفارشی Authenticate و Authorize) دارند و در اینجا مجال پرداختن به آن وجود ندارد.
در یک جمع بندی خلاصه می توان چنین گفت که Global.asax امکان مشارکت یا اصطلاحا Subscribe در مراحل مختلف IIS Processing Pipeline که همان مسیر یا مقاطع متعدد و متنوع پردازش در تکنولوژی ASP .NET است ) از مرحله دریافت Request تا مرحله پایانی ارسال Response) را فراهم میکند. در زیر لیستی از رویداد های Synchronous را مشاهده میکنید:

1. BeginRequest
2. AuthenticateRequest
3. PostAuthenticateRequest
4. AuthorizeRequest
5. PostAuthorizeRequest
6. ResolveRequestCache
7. PostResolveRequestCache
8. MapRequestHandler
9. PostMapRequestHandler
10. AcquireRequestState
11. PostAcquireRequestState
12. PreRequestHandlerExecute
اینجا مرحله ایست که پردازش های Page Handler در ASP .NET آغاز میشود
13. PostRequestHandlerExecute
14. ReleaseRequestState
15. PostReleaseRequestState
16. UpdateRequestCache
17. PostUpdateRequestCache
18. LogRequest
19. PostLogRequest
20. EndRequest

دلیل اصلی اینکه ما Global.asax را به عنوان نقطه شروع کالبد شکافی پروژه های MVC انتخاب کردیم این است که طراحان MVC جزییات مربوط به منطق Config و تنظیمات پایه و عمل ثبت و Register کردن آنها را در رویداد Application_Start فایل Global.asax قرار داده اند که چنانچه از نام این رویداد نیز مشخص است یک رویداد Application Level محسوب شده و به ازای هر بار اجرای Application (فراموش نکنیم که رایج ترین روش اجرای یک Application مبتنی بر وب ، درخواست یا Request می باشد که به طور معمول با تایپ آدرس یا URL برنامه در مرورگر انجام میشود) متد وابسته به این رویداد اجرا خواهد شد.

 

protected void Application_Start(){
   AreaRegistration.RegisterAllAreas();
   WebApiConfig.Register(GlobalConfiguration.Configuration);
   FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
   RouteConfig.RegisterRoutes(RouteTable.Routes);
   BundleConfig.RegisterBundles(BundleTable.Bundles);
   AuthConfig.RegisterAuth();
}

در میان مواردی که در کد مشاهده میکنید در حال حاضر فراخوانی متد استاتیک RegisterRoutes کلاس RouteConfig بیشتر از سایرین مورد توجه ما می باشد .
اما در یک نگاه اجمالی واضح است که منشاء بسیاری از تنظیمات و Config اولیه MVC از همینجا آغاز میشود. به عنوان مثال RegisterBundles عملیات بسته بندی بخشهای استاتیک سایت ، مواردی نظیر Stylesheet و کد های Client-side و کتابخانه های JQuery را بر عهده دارد. هدف از این بسته بندی در درجه اول این است که اطلاعات این فایلهای استاتیک را ضمن نوعی فشرده سازی در یک بسته واحد متمرکز نموده و استفاده از آنها در مراحل مختلف پروژه با سرعت و کیفیت بالاتری میسر گردد. همچنین متد استاتیک RegisterAuth وظیفه الحاق کتابخانه های مورد نیاز برای استفاده از روش OAuth را در MVC فراهم میسازد .
نکته : همینطور که در مسیر این بررسی جلوتر می رویم، بهانه های متعددی برای انحراف از مسیر اصلی وجود دارد که من عمدا بدون توجه به آنها فقط به مواردی که جهت ایجاد یک دیدگاه کلی از پروژه های MVC الزامی هستند توجه خواهم کرد .
چنانچه اشاره شد فراخوانی متد استاتیک RegisterRoute نقطه آغاز تنظیمات Routhing در MVC می باشد که در حال حاضر موضوع اصلی بحث ما خواهد بود.
یقین دارم که ارائه یک معادل فارسی برای Routhing هیچ کمکی به درک نقش آن نخواهد کرد پس بنابراین من در سرتاسر این مطلب صرفا از همین اصطلاح استفاده خواهم کرد و در اینجا فقط به وظایف و نقش بسیار کلیدی آن خواهم پرداخت .
مفهوم Routhing در MVC به طور مشخص برای تفسیر URL و قسمت های مختلف آن که Segment یا قطعه نامیده میشوند به کار میرود. چنانچه از قبل مطلع هستیم به طور معمول یک URL معتبر معمولا دارای Segment های مختلفی است که هر Segment با استفاده از علامت / از سایرین متمایز میشود .
تا قبل از MVC و مخصوصا در ASP .NET Web Form با ملاحظه یک URL نمونه مثل :

http://example.com/albums/list.aspx?catid=17313&genreid=33723

اطلاعات بسیار مفیدی در آن مشاهده میکنیم که صرفنظراز بسیاری از جزییات موجود در آن، توجه به این نکته مهم ضروری است که تا قبل از MVC یک تناظر مشخص بین URL و ساختار فایلها و فولدرهای Application وجود داشته و در URL مثال قبل بدون هیچ تردیدی می توان دریافت که قطعا فایلی به نام List.aspx در فولدری به نام Albums در یک Domain ثبت شده به نام Example.com وجود دارد که کاربر با تایپ URL فوق ، با استفاده از پروتکل http قصد دریافت سرویس (یا اجرای برنامه) موجود در آدرس مذکور را داشته است. مجددا آنچه از ظواهر امر پیداست، این است که کاربر با ارسال اطلاعاتی که بعد از علامت ? قرار دارد اصطلاحا با ارسال یک Query String قصد دارد لیستی از آلبومهای خاصی از یک موضوع یا ژانر خاص را مشاهده نماید.
در MVC این تناظر ساختار فایلها با فولدرها دیگر معتبر نبوده (یا حداقل به شدت قبل نیست) و همه چیز وابسته به تفسیری است که Routhing انجام داده و حاصل تفسیر این اطلاعات در این تکنولوژِی (یعنی MVC) مستقیما در اختیار Controller قرار داده میشود که به نحوی که به آن اشاره خواهیم کرد، مسیر پردازش و نحوه ارسال پاسخ یا Response را مشخص نماید .
پس در یک جمع بندی در ابتدا فایل Global.asax در رویداد Application_OnStart متد استاتیک RegisterRoutes را فراخوانی میکند . پارامتر این متد یعنی RouteTable.Routes یک نمونه یا Instance از کلاس RouteCollection می باشد که در یک تعبیر ساده، کلکسیونی از مسیر های قابل درک برنامه ما را در خود ذخیره میکند. این کلکسیون شامل آیتم هایی است که به طور معمول در MVC ما برای پردازش آنها به ازای هر یک از آنها متدی از کلاس Controller را در نظر گرفته ایم . البته باید توجه داشت که در MVC کماکان امکان پردازش فایلهای استاتیک پیش بینی شده است و ما در مورد این موضوع در مباحث مربوط به View بیشتر صحبت خواهیم کرد .
در فولدر App_Start کلاس RouteConfig وظیفه ثبت مسیرهای مورد نظر در برنامه ما را به عهده دارد در پیاده سازی پیش فرض این کلاس ما بوضوح مشاهده خواهیم کرد که در طول فراخوانی متد RegisterRoute که در Global.asax انجام میشود چه عملیاتی انجام میشود:

public class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);
}
}

در ابتدا و در سطر اول، ملاحظه میکنید که فراخوانی متد IgnoreRoute ظاهرا از هر گونه دسترسی مستقیم کاربر به فایلهای Resource مشخص شده با پسوند .axd جلوگیری میکند. شاید جالب باشد که بدانید در واقع عملا هیچ فایلی با پسوند axd در پروژه ما وجود ندارد!!!! اما در ASP .NET با استفاده از یک ترفند ویژه به طور معمول برخی از اطلاعات استاتیک پروژه نظیر کد های Javascript و حتی Image ها که اغلب آنها را Resource یا منابع پروژه می نامیم به صورت Dynamic در قالب فایلهایی با پسوند .axd تبدیل شده و برای تکمیل پروسه Render و نمایش در Browser نقش آفرینی میکنند .
اما اولین و مهمترین مسیر مجاز با فراخوانی MapRoute در RouteCollection ثبت میگردد که اصطلاحا به آن مسیر پیش فرض یا Default Route گفته میشود . این وضعیت تا حد بسیار زیادی مشابه با تعیین Defaullt Document در ASP .NET Web Form می باشد که خوانندگان محترم قطعا با این مفهوم آشنا می باشند .
آنچه به طور دقیق توسط فراخوانی متد MapRoute در سطر دوم انجام میشود این است که ما به عنوان طراح اصلی برنامه مشخص میکنیم که URL مورد نظر برای دستیابی به برنامه ما می تواند حداکثر شامل سه Segment یا قطعه باشد که به ترتیب با استفاده از سه Placeholder (نام جایگزین) با نامهای Controller و action و id آنها را مشخص کرده ایم. اسامی جایگزین یا همان Placeholder ها در داخل یک جفت {} تایپ شده و هر Segment با یک علامت / از دیگری جدا شده است .
همچنین در ادامه برای هر یک از این سه قطعه قواعدی مشخص نموده ایم که مشخصات این قواعد را به طور دقیق در defaults به طور واضح بیان میکنیم. ما برای controller مقدار پیش فرض home و برای action (که در واقع متد های Public موجود در کلاس Controller به عنوان جزء اصلی پردازش هر مسیر هستند) مقدار پیش فرض Index را در نظر گرفته ایم. با ذکر UrlParameter.Optional ، صریحا ذکر id را اختیاری یا Optional تعیین کرده ایم .
اگر فرض کنیم که نام پروژه ما MVCPreview باشد در این صورت مسیر های زیر برای برنامه ما مجاز محسوب خواهند شد :

1) http://MVCPreview/Home/Index/210
2) http://MVCPreview/Home/Index/
3) http://MVCPreview/Home
4) http://MVCPreview/
 

در حالت اول نتیجه پردازش Routhing این است که برای Placeholder های id و action و controller به ترتیب مقادیر 210 و index و Home تعیین شده است . در واقع URL مذکور شامل سه Segment می باشد که با شرط ذکر شده در فراخوانی متد MapRoute (یعنی "{controller}/{action}/{id}") کاملا منطبق است . به عبارت ساده تر در URL مذکور ما صریحا مشخص کرد ه ایم که مسیر پردازش به متد Index (که نقش action را عهده دار است) در کلاس Home (که نقش Controller را ایفا میکند) هدایت شده و مقدار 210 به عنوان پارامتر و جایگزین id در اختیار این متد قرار بگیرد .
در حالت دوم مقدار جایگزین برای id ذکر نشده که با توجه به UrlParameter.Optional توسط Routhing همچنان به عنوان یک مسیر معتبر تفسیر شده و مسیر پردازش به متد Index در Controller هدایت خواهد شد.
در حالت سوم از ذکر نام action خود داری شده ولی باز به دلیل ارائه مقدار Default در فراخوانی MapRoute یعنی درست با ذکر action = "Index" مفسر Routhing به صورت خودکار جای خالی action را با مقدار index تامین خواهد کرد. بنابراین مجددا این URL نیز توسط Routhing معتبر و مجاز تشخیص داده شده و مسیر پردازش درست به مانند دو حالت قبل ادامه خواهد یافت.
در حالت چهارم هر سه Segment غایب هستند و این بار هم مجددا عدم وجود Controller توسط controller = "Home" جبران شده و مقدار Home در اینجا مشخص میکند که عدم ذکر نام Controller به معنی انتخاب Controller ی به نام Home خواهد بود و نتیجه آنکه مجددا این URL نیز معتبر و مجاز تشخیص داده شده و مسیر پردازش به متد Index در کلاس Controller ما یعنی Home هدایت میشود .
 

....ادامه دارد