مطالب
افزونه تاریخ فارسی برای outlook 2007

عموما در محیط کاری اگر شبکه ویندوزی و mail server مورد استفاده هم ms exchange باشد، به طور قطع از outlook برای انجام امور روزمره ارسال و دریافت ایمیل استفاده می‌شود.
طبق معمول هم مشکل ما تاریخ فارسی است! یکی از شرکت‌های ایرانی که در این‌باره محصولی را ارائه داده با hook کردن تاریخ ویندوز، هر جایی که تاریخی قرار است نمایش داده شود، آنرا فارسی می‌کند. این محصول دو ایراد دارد: الف) رایگان نیست! ب) این hook بر روی عملکرد سایر برنامه‌ها تاثیرگذار است. برای مثال برنامه‌های دات نت تاریخ قمری را نمایش خواهند داد، بر روی عملکرد و کارآیی کلی سیستم تاثیر منفی دارد و مشکلاتی از این دست.

افزونه زیر بدون دستکاری تاریخ ویندوز، دو کار را در MS outlook 2007 انجام خواهد داد:

الف) اضافه کردن ستون "تاریخ دریافت" شمسی



ب) در متن دریافتی، تمام تاریخ‌های sent موجود را یافته و شمسی می‌کند



دریافت افزونه:
لطفا اینجا کلیک کنید.

تذکر مهم:
نصب دو بسته به روز رسانی سیستم و دات نت فریم ورک را پیش از نصب این افزونه فراموش نکنید.
/Post/14/افزونه-فارسی-به-پارسی-برای-word-2007


در کل برای من کار راه انداز بوده :)

در طی روزهای آتی، سورس کامل و نحوه برنامه نویسی آن‌را بررسی خواهیم کرد.

مطالب
خلاصه اشتراک‌های روز پنج شنبه 19 آبان 1390
نظرات مطالب
نگاشت JSON به کلاس‌های معادل آن
منهای کاربردهای Ajax ایی، هستند برنامه‌هایی که از JSON برای تبادل اطلاعات استفاده می‌کنند (این وب سرویس‌های غنی دات نت که به این سهولت در زبان‌های دیگر در دسترس نیست). مثلا برنامه utorrent یک API مبتنی بر JSON دارد (utorrent web-api). به این ترتیب می‌شود به آن فایل اضافه کرد، کم کرد، درخواست دریافت داد، آمار درصد دریافت فایل‌ها رو گرفت و غیره. اینجا است که نیاز پیدا می‌کنید بتونید JSON رو دقیق Parse کنید.
یا مثلا گوگل یک سری API خاص خودش را دارد و بعضی از این‌ها فقط خروجی JSON دارند: google data
مطالب
لینک‌های هفته‌ی اول بهمن

وبلاگ‌ها ، سایت‌ها و مقالات ایرانی (داخل و خارج از ایران)

Visual Studio


ASP. Net


طراحی و توسعه وب


اس‌کیوال سرور


سی شارپ


عمومی دات نت


ویندوز


مسایل اجتماعی و انسانی برنامه نویسی


متفرقه

مطالب
برنامه نویسی اندروید با Xamarin.Android - قسمت اول
وقتی صحبت از ساخت برنامه‌های کاربردی iOS و Android می‌شود، بسیاری از افراد تنها گزینه را Objective-C یا Java می‌دانند. اما در این چند سال اکوسیستم‌هایی (مجموعه ای از ابزارها) برای ایجاد برنامه‌های کاربردی موبایل ظهور کرده‌اند و البته تمرکز آن‌ها بر روی Cross Platform بودن آن‌ها بوده است. هر کدام از آن‌ها قابلیت‌هایی را برای ما به ارمغان می‌آورند. البته بعضی فقط به ما امکان نوشتن کدهای Html و Java Script را می‌دهند و برخی دیگر از کدهای C++/C که کدهای low-level هستند، استفاده می‌کنند.
ما در اینجا قصد معرفی Xamarin را داریم. تنها پلتفرمی که تمام امکانات بومی موبایل را به همراه امکانات بسیار دیگری، برای ما فراهم می‌کند. این امکانات شامل موارد ذیل هستند:
1- اتصال کامل به SDK بومی: Xamarin شامل اتصالاتی برای استفاده از تمامی (تقریبا) امکانات iOS و Android می‌باشد. این اتصالات به صورت Strongly-typed هستند. به این معنا که برای بررسی و استفاده، آسان هست و همچنین در حین توسعه و کامپایل به خوبی صحت کد‌ها را چک می‌کند.
2- قابلیت ارتباط با Objective-C،Java، C،C : زامارین امکاناتی را برای فراخوانی مستقیم کتابخانه‌هایی که با Objective-C، Java، C و ++C نوشته شده‌اند، نیز فراهم کرده است. این یک امکان فوق العاده هست که شما بتوانید از تعداد بسیار زیاد کتابخانه‌های نوشته شده برای iOS و Android استفاده کنید.
3- استفاده از زبان مدرن #C: برنامه‌های Xamarin با #C نوشه می‌شوند که بهبود‌های قابل توجهی نسبت به زبان‌های Objective-C و Java داشته است. امکاناتی مانند عبارات لامبدا، LINQ، برنامه نویسی موازی و ....
4- مجموعه کلاس‌های فوق العاده: برنامه‌های Xamarin از Net BCL. که مجموعه‌ای عظیم و جامع از ویژگی‌های قدرتمند، مانند استفاده از XML، بانک اطلاعاتی، شبکه، IO و ...است، استفاده می‌کند که امکانات فوق العاده‌ای را برای توسعه دهندگان فراهم می‌نماید.
5- استفاد ه از یک IDE قدرتمند: برای Mac OS X شما Xamarin Studio  و برای ویندوز Xamarin Studio و Visual Studio را در اختیار دارید که برای یک توسعه دهنده‌ی نرم افزار چیزی را کم نگذاشته‌اند.
6- Cross Platform بودن: Xamarin برای سه پلتفرم مطرح موبایل، شامل iOS، Android و Windows Phone قابل استفاده می‌باشد و تقریبا 90 درصد از کدهای شما قابل استفاده‌ی مجدد در هر سه پلتفرم می‌باشد.
البته با ارائه‌ی Xamarin.Forms این میزان به 100درصد رسیده است!

نحوه‌ی نصب Xamarin:
می‌توانید Xamarin Studio و Xamarin For Visual Studio را از سایت Xamarin دانلود نموده و به راحتی نصب نمایید. برای آنکه بتوانید Xamarin را نصب و استفاده نمایید، لازم است که موارد زیر را نیز به روی سیستم خود داشته باشید:
1- Android SDK  
2- GTK#
3- Android NDK
4- Java SDK(JDK)
هر آنچه را که برای ادامه‌ی مسیر با ما لازم دارید، از ehsanavr.com دانلود نمایید.
 و البته نحوه‌ی نصب Xamarin به صورت کامل و همراه با تصاویر مربوطه نیز در آدرس زیر وجود دارد:

Emulator یا شبیه ساز اندروید: Xamarin یک شبیه ساز بسیار عالی برای تست برنامه‌های اندرویدی در اختیار ما قرار داده است که از Virtual Box استفاده می‌کند. می‌توانید این نرم افزار را با نام Xamarin Android Player از اینجا دانلود نمایید. بعد از نصب و اجرای آن شما باید Imageهای مربوط به هر نسخه‌ای را که میخواهید، دانلود کنید:

Xamarin Android Player


  
کمی درباره سطوح مختلف APIهای اندروید:
اندروید برای تشخیص سازگاری برنامه‌های اندروید، از سطوح مختلف APIها(API Levels) استفاده می‌کند. هر سطح از این APIها یک ورژن از اندروید را شامل می‌شوند. برای مثال Marshmallow که به اندروید 6 معروف می‌باشد، از API Level شماره 23 بهره می‌برد و Lollipop نسخه‌ی 5، شامل API Level شماره 21 و Lollipop 5.1 شامل API Level شماره 22 می‌باشد و الی آخر.
اهمیت دانستن این موضوع، به این دلیل می‌باشد که انتخاب API Level مناسب، ارتباط مستقیمی با موبایل هایی دارد که می‌توانند برنامه‌ی شما را اجرا کنند. می‌توانید لیست کامل API‌های موجود را از اینجا مشاهده نمایید:

برای هر برنامه‌ی اندروید نوشته شده، 3 تنظیم برای SDK مورد استفاده قرار می‌گیرد:
Target Framework: مشخص کننده‌ی نوع فریموورکی می‌باشد که برنامه با آن کامپایل می‌شود.
Minimum Android Version: مشخص کننده‌ی قدیمی‌ترین نسخه‌ی اندرویدی می‌باشد که می‌خواهید برنامه‌ی شما روی آن اجرا شود. این API Level در زمان اجرا استفاده می‌شود.
Target Android Version: نسخه‌ای را که برنامه‌ی شما بر روی آن اجرا می‌شود، مشخص می‌نماید. این API Level در زمان اجرا استفاده می‌شود. همیشه میزان این API Level باید برابر یا بیشتر از Target Framework باشد.
البته معمولا این سه تنظیمات را روی یک API Level تنظیم می‌کنند.
قبل از اینکه بخواهید API Level مورد نظر را انتخاب کنید، باید SDK مربوط به آن را دانلود و نصب نمایید. برای مدیریت نسخه‌های SDKهای نصب شده بر روی سیستم خود می‌توانید از Android SDK Manager که در فولدر SDK قرار دارد می‌توانید استفاده نمایید.


کمی درباره‌ی معماری Xamarin:
برنامه‌های نوشته شده در Xamarin.Android در محیط Mono اجرا می‌شوند و Mono در کنار ماشین مجازی زمان اجرای اندروید، اجرا می‌شود. این دو سیستم روی هسته‌ی لینوکس اجرا می‌شوند و APIهای مختلفی را در اختیار برنامه نویسان قرار می‌دهند. Mono با زبان C نوشته شده است. شما می‌توانید کلاس‌های NET. مانند: System، System.IO، System.Net را برای دسترسی به قابلیت‌های لینوکس مورد استفاده قرار بدهید.
در اندروید، بیشتر قابلیت‌های سیستم مانند صدا، گرافیک، OpenGL و قابلیت‌های تلفن، مستقیم در دسترس برنامه‌های بومی(Native) نیستند. آن‌ها فقط از طریق APIهای Android Runtime Java در دسترس هستند که در فضای نام Java.* یا Android.* قرار داردند. تصویر زیر این توضیحات را به خوبی نشان می‌دهد.
 

Xamarin

توسعه دهندگان Xamarin.Android به امکانات مختلفی از سیستم عامل با فراخوانی API‌های NET. دسترسی دارند و همچنین کلاس‌های موجود در فضای نام Android، پُلی برای استفاده از API‌های اندروید توسط برنامه نویسان Xamarin می‌باشد.
نکته‌ی مهم دیگر این است که Packageهای برنامه‌های نوشته شده با Xamarin ساختاری شبیه به برنامه‌های معمول اندرویدی دارد، البته همراه با موارد زیر:
1- اسمبلی‌های برنامه (شامل IL)
2- کتابخانه‌های بومی، که باید حتما برنامه‌های Xamarin.Android کتابخانه‌های زمان اجرای مناسب با معماری اندروید مانند:armeabi، armeabi-v7a، x86 را در اختیار داشته باشد.

در بخش بعد اولین برنامه‌ی اندرویدی خود را با Xamarin اجرا می‌نماییم.
مطالب
با ASP.MVC چه مزایایی را به دست خواهیم آورد
عموما در اکثر مطالب مقایسه‌ای بین وب فرم‌ها و ASP.NET MVC به جداسازی بهتر منطق کدها از فرم‌ها و قابلیت بهتر تهیه آزمون‌های واحد اشاره می‌شود. در این مطلب از دیدگاهی دیگر به این مساله خواهیم پرداخت؛ از لحاظ فنی و جدای از مسایل یاد شده، چه مزایای دیگری را می‌توان با استفاده از ASP.NET MVC نسبت به وب فرم‌ها به دست آورد؟

1- آدرس‌های تمیزتر
در ASP.NET MVC به صورت پیش فرض از سیستم Routing موجود در زیر ساخت ASP.NET برای نمایش Urlهایی بدون پسوند استفاده می‌شود. همچنین این سیستم امکان تهیه آدرس‌هایی با سازگاری بهتر با موتورهای جستجو را نیز از ابتدا مدنظر داشته است.
بله. این زیر ساخت در اختیار وب فرم‌ها نیز هست؛ اما فرق است بین حالتی که از ابتدا مجبور شویم تمیزتر کار کنیم با زمانیکه این انتخاب را داریم و ... عموما هم از آن در وب فرم‌ها استفاده نمی‌شود.

2- عدم وابستگی الزامی به فایل‌های فیزیکی موجود در سیستم
کلیه درخواست‌ها در MVC برخلاف وب فرم‌ها در بدو امر به فایل‌های موجود در سیستم منتقل نمی‌شوند. درخواست‌ها به متدهای موجود در کنترلرها منتقل می‌شوند. همین مساله سبب می‌شود که آدرس‌ها الزاما به یک فایل فیزیکی موجود در سیستم اشاره نکنند. به این ترتیب می‌توان درخواست‌ها را بر اساس شرایط، به Viewهای مختلف هدایت کرد و نه اینکه هر درخواست ابتدا به یک view رسیده و سپس به متدی ارجاع داده شود.
این مساله از لحاظ امنیتی نیز مهم است. درخواست‌های رسیده به MVC سبب اجرای هیچ فرمی نخواهند شد. درخواست‌ها حتما باید از فیلتر یک کنترلر عبور کنند تا اجرایی شوند.

3- امکان مدیریت بهتر قسمت‌های مختلف سایت در پوشه‌های جداگانه
اگر به سورس اکثر سایت‌های مبتنی بر ASP.NET Web forms توجه کنیم، تمام فایل‌های آن‌ها در ریشه سایت قرار دارند منهای فایل‌های CSS و JS و تصاویر. در ASP.NET MVC از ابتدای کار، هر قسمت از سایت در پوشه‌های جداگانه‌ای قرار می‌گیرد و به این ترتیب مدیریت فایل‌ها و نظم دهی به آن‌ها ساده‌تر خواهد بود.

4- امکان تعریف تمام اجزای یک فرم یا view به صورت strongly typed
در ASP.NET MVC می‌توان یک کلاس را به یک فرم یا View نسبت داد. به این ترتیب کنترل‌های web forms تبدیل به خواص این کلاس در MVC خواهند شد. مزیت این امر امکان کنترل تمام اجزای فرم‌های سایت توسط کامپایلر است.
به این ترتیب اگر در طی یک حلقه، جدولی را ایجاد کنیم، تمام عناصر تشکیل دهنده این حلقه (چه کدهای آن و چه المان‌هایی که اطلاعات را در صفحه نمایش می‌دهند) نیز توسط کامپایلر قابل بررسی و خطایابی هستند.

5- مقدار دهی خودکار مدل متناظر با یک فرم یا View در ASP.NET MVC
روال متداول کار با وب فرم‌ها، قرار دادن تعدادی کنترل در صفحه و سپس دریافت دستی مقادیر آن‌ها در فایل code behind است. در MVC دیگر نیازی نیست تا این کارها را دستی انجام دهید. به یک فرم یا View کلاسی را انتساب خواهید داد. فریم ورک خواص آن‌را به صورت خودکار در حین ارسال به سرور مقدار دهی خواهد کرد. این مورد حتی در حین کار با jQuery Ajax نیز صادق  است.
این مساله کار با ORMها را نیز ساده‌تر می‌کند. از این جهت که تمام آن‌ها نهایتا با یک سری مدل و کلاس کار خواهند کرد و تمام فیلدها و جداول به تعدادی کلاس و خاصیت تعریف شده در آن‌ها نگاشت می‌شوند.
به این ترتیب چون دیگر نیازی به ارجاع مستقیم به اشیاء بصری در فایل‌های code behind که در اینجا کنترلر نام گرفته‌اند نیست، نوشتن آزمون واحد برای این کلاس‌ها نیز به شدت ساده‌تر شده است.

6- ASP.NET MVC به همراه یک فرم ساز توکار ارائه می‌شود
اگر کسی به شما گفته است که سرعت کار با ASP.NET MVC پایین است به طور قطع دو فصل اول یک کتاب MVC را بیشتر مطالعه نکرده است. در MVC یک کلاس متناظر با فرمی را طراحی می‌کنید. توسط ابزار scaffolding همراه با VS.NET از روی این کلاس و مدل، با چند کلیک یک فرم تولید خواهد شد. فرمی که حتی مقدار دهی و انتساب عناصر بصری آن به کلاس متناظر با آن نیز خودکار است.
سرعت پیاده سازی یک برنامه با ASP.NET MVC به مراتب بیشتر است از کار با وب فرم‌ها.

7- حذف View State در MVC
از آنجائیکه فرم‌های ASP.NET Web forms از نوع strongly typed نیستند (در دات نت 4 و نیم اندکی بهبود در حد گرید‌های آن حاصل شده البته)، برای اینکه پس از ارسال یک فرم به سرور باز هم کنترل‌های نمایش داده شده در صفحه همان مقادیر قبلی را نمایش دهند، مکانیزم View State به همراه ذخیره سازی اطلاعات فرم در فیلدهای مخفی فرم جاری طراحی شد.
در MVC نیازی به این مکانیزم نیست. زیرا فقط کافی است که اطلاعات مدل را مجددا به View ارسال کنیم. نمایش و انتساب نهایی آن در اینجا خودکار است. بنابراین نیازی به View State وجود ندارد.

8- کنترل بهتر بر روی اعتبار سنجی اطلاعات دریافتی
در وب فرم‌ها اگر بخواهیم سیستم اعتبارسنجی آن‌را غیرفعال کنیم، مثلا برای دریافت html از کاربر، نیاز است کلا آن‌را از کار بیندازیم (یا در سطح فرم یا در سطح کل برنامه). در MVC می‌توان این اعتبار سنجی را تنها در سطح یک خاصیت که قرار است اطلاعات HTML ایی را دریافت کند، غیرفعال کرد؛ نه برای کل فرم و نه در سطح کل برنامه.

9- امکان استفاده از فرم‌های و Viewهای Razor بجای موتور وب فرم‌ها
در وب فرم‌ها تا این زمان فقط محدود به تنها موتور نمایشی مخصوص به آن هستیم. اما در MVC این محدودیت برداشته شده و تا به حال چندین و چند View engine در این بین توسط مایکروسافت و سایر برنامه نویس‌ها طراحی شده است. مهم‌ترین آن‌ها Razor است که تمام برنامه نویس‌های MVC پس از مدتی به روان بودن و طراحی طبیعی و عالی آن اعتراف دارند.

10- امکان تعریف بیش از یک فرم در صفحه
طراحی ASP.NET Web forms از روز اول آن محدود به یک فرم در صفحه بوده است. این محدودیت در MVC برداشته شده و مزیت آن امکان ارسال اطلاعات قسمت‌های مختلف یک فرم به کنترلرهای مختلف و جداسازی بهتر کدهای قسمت‌های مختلف برنامه است.

11- امکان Refactoring بهتر کدهای تکراری در ASP.NET MVC به کمک مفهوم فیلترها
فیلترها در MVC یک سری attribute هستند که می‌توان آن‌ها را به متدهای کنترلرها اعمال کرد و به صورت خودکار توسط فریم ورک پیش یا پس از اجرای یک متد اجرا می‌شوند. به این ترتیب حجم قابل ملاحظه‌ای از if و else‌ها را می‌توان در این فیلترها کپسوله کرد و کدهای متدهای کنترلرها را تمیزتر و زیباتر نمود.

12- سازگاری کامل با jQuery و jQuery Ajax و کلا انواع و اقسام فریم‌ورک‌های جاوا اسکریپتی
در MVC وب کنترل‌ها کنار گذاشته شده‌اند و سعی شده است با وب به همان نحو که هست برخورد شود. به این ترتیب اگر نیاز داشتید، کل دکمه‌های فرم را با spanها جایگزین کرده و توسط فریم ورک‌های CSS ایی تزئین کنید، بدون نیاز به نگارش جدیدی از ASP.NET MVC، باز هم برنامه کار خواهد کرد.
یا برای کار با اجزای مختلف فرم از ده‌ها و صدها افزونه موجود برای jQuery به سادگی می‌توان استفاده کرد. برای نمونه کل سیستم اعتبار سنجی توکار MVC با اعتبار سنجی jQuery یکپارچه و جایگزین شده است.
یا برای کار با jQuery Ajax نیازی نیست تا متدی را static تعریف کنید و به این ترتیب از مزایای امنیتی توکار ASP.NET محروم شوید (مثلا دسترسی به شیء User اعتبار سنجی مبتنی بر فرم‌ها). یا اگر فرم شما 10 فیلد دارد، کل این فیلدها به صورت خودکار به خواص متناظر با آن‌ها نگاشت خواهد شد و نیازی نیست برای این مورد کد بنویسید. به علاوه باید درنظر داشت که jQuery Ajax نسبت به فریم ورک Ajax همراه با ASP.NET web forms بسیار سبک‌تر و سریعتر عمل می‌کند چون نیازی ندارد تا هر بار View state را نیز به سرور ارسال کند.
همچنین در اینجا دیگر ID کنترل‌های مورد استفاده در اسکریپت‌ها به صورت خودکار تولید نمی‌شوند و برنامه نویس از ابتدای امر کنترل کاملی را روی این مساله دارد.

13- امکانات فشرده سازی css و js بهتر
در MVC 4 سیستم bundling آن از نمونه مشابه موجود در وب فرم‌ها کامل‌تر است و جهت فشرده سازی و یکی کردن هر دو مورد فایل‌های css و js می‌تواند بکارگرفته شود؛ به همراه تنظیمات کش مرورگر و gzip خودکار حاصل. به علاوه این سیستم را سفارشی سازی نیز می‌توان ساخت و بهینه سازی عملکرد آن مطابق نیاز میسر است.

14- یکپارچگی بهتر EF Code first با MVC
عنوان شد که وجود مدل‌ها و فرم‌های strongly typed یکی از مزایای کار با MVC است و ORMها نیز نهایتا با همین کلاس‌ها هستند که کار می‌کنند. در MVC سیستم کد سازی به نام scaffolding وجود دارد (تهیه شده توسط خود مایکروسافت) که می‌تواند بر اساس مدل‌های EF code first شما، قسمت عمده‌ای از کدهای یک برنامه ASP.NET MVC را تولید کند. سپس می‌توانید به سفارشی سازی آن مشغول شوید.

15- تزریق وابستگی‌ها در MVC ساده‌تر است
در هر دو فریم ورک وب فرم‌ها و MVC امکان تزریق وابستگی‌ها وجود دارد. اما در MVC می‌توان در میانه کار وهله سازی کنترلرها، دخالت کرد و کنترل آن را کاملا در دست گرفت. همین امر سبب می‌شود حین کار با کتابخانه‌های تزریق وابستگی‌ها در ASP.NET MVC حجم کد نویسی به شدت کاهش پیدا کند.

16- امکانات امنیتی MVC بیشتر است
عنوان شد که در MVC می‌توان اعتبار سنجی را تنها در حد یک خاصیت غیرفعال کرد. فیلتر مبارزه با حملات CSRF جزئی از فریم ورک MVC است. به همراه فیلتر Authorize آن که باز هم اعمال سفارشی سیستم اعتبار سنجی مبتنی بر فرم‌ها را ساده‌تر می‌کند با امکان یکپارچگی بهتر با Role providerهای سفارشی.
و یا برای نمونه Razor به صورت پیش فرض امن طراحی شده است. خروجی Razor همواره و در بدو امر، html encoded است مگر اینکه برنامه نویس آگاهانه آن‌را تغییر دهد. این مورد مقاومت در برابر حملات XSS را بالا خواهد برد.
امکان استفاده از فیلترهای سفارشی که عنوان شد، جهت مسایل امنیتی بسیار کاربرد دارند. برای مثال بررسی referrer فرم ارسال به سرور را درنظر بگیرید. در وب فرم‌ها می‌توان این‌کار را با یک http module که روی کل برنامه تاثیر گذار است انجام داد. اما در MVC این فیلتر را تنها می‌توان بر روی یک فرم خاص عمومی برای مثال اعمال کرد و نه کل برنامه.
مطالب
ASP.NET MVC #2

MVC‌ چیست و اساس کار آن چگونه است؟

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


C در MVC معادل Controller است. کنترلر قسمتی است که کار دریافت ورودی‌های دنیای خارج را به عهده دارد؛ مانند پردازش یک درخواست HTTP ورودی.


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



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

اگر پیشتر با ASP.NET Web forms کار کرده باشید اکنون شاید این سؤال برایتان وجود داشته باشد که این سیستم جدید در مقایسه با نمونه قبلی، چگونه درخواست‌ها را پردازش می‌کند.


همانطور که مشاهده می‌کنید، در وب فرم‌ها زمانیکه درخواستی دریافت می‌شود، این درخواست به یک فایل موجود در سیستم مثلا default.aspx ارسال می‌گردد. سپس ASP.NET یک کلاس وهله سازی شده معرف آن صفحه را ایجاد کرده و آن‌را اجرا می‌کند. در اینجا چرخه طول عمر صفحه مانند page_load و غیره رخ خواهد داد. جهت انجام این وهله سازی، View به فایل code behind خود گره خورده است و جدا سازی خاصی بین این دو وجود ندارد. منطق صفحه به markup آن که معادل است با یک فایل فیزیکی بر روی سیستم، کاملا مقید است. در ادامه، این پردازش صورت گرفته و HTML نهایی تولیدی به مرورگر کاربر ارسال خواهد شد.
در ASP.NET MVC این نحوه پردازش تغییر کرده است. در اینجا ابتدا درخواست رسیده به یک کنترلر هدایت می‌شود و این کنترلر چیزی نیست جز یک کلاس مجزا و مستقل از هر نوع فایل ASPX ایی در سیستم. سپس این کنترلر کار پردازش درخواست رسیده را شروع کرده، اطلاعات مورد نیاز را جمع آوری و سپس به View ایی که انتخاب می‌کند، جهت نمایش نهایی ارسال خواهد کرد. در اینجا View این اطلاعات را دریافت کرده و نهایتا در اختیار کاربر قرار خواهد داد.



آشنایی با قرارداد یافتن کنترلرهای مرتبط

تا اینجا دریافتیم که نحوه پردازش درخواست‌ها در ASP.NET MVC بر مبنای کلاس‌ها و متدها است و نه بر مبنای فایل‌های فیزیکی موجود در سیستم. اگر درخواستی به سیستم ارسال می‌شود، در ابتدا، این درخواست جهت پردازش، به یک متد عمومی موجود در یک کلاس کنترلر هدایت خواهد شد و نه به یک فایل فیزیکی ASPX (برخلاف وب فرم‌ها).


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

برای مثال در اینجا فریم ورک به دنبال کلاسی به نام ProductsController خواهد گشت.
شاید تعدادی از برنامه نویس‌های ASP.NET MVC تصور ‌کنند که فریم ورک در پوشه‌ی استانداردی به نام Controllers به دنبال این کلاس خواهد گشت؛ اما در عمل زمانیکه برنامه کامپایل می‌شود، پوشه‌ای در این اسمبلی وجود نخواهد داشت و همه چیز از طریق Reflection مدیریت خواهد شد.