بله این امکان رو یاهو هم میدهد.
ولی استفاده از گوگل خیلی خوش دست‌تر و راحت‌تر هست.
بر اساس جستجوهایی که انجام داده‌ام، CHM پشتیبانی کاملی را از یونیکد انجام نمی‌دهد (مشکل جستجو و همچنین ایندکس کردن).
اما با ترفندی میتوان این مساله را حل کرد و آن هم تبدیل encoding فایل‌ها به عربی است (windows-1256). در این حالت هم جستجو کار می‌کند و هم عنوان صفحات هنگام جستجو در لیست موارد یاد شده درست نمایش داده می‌شود و صفحه add to favorites نیز مشکلی در نمایش عنوان‌های صفحه‌ها نخواهد داشت. روش کار به شرح زیر است:
الف) encoding تمام فایل‌های html خود را به صورت زیر تغییر دهید (از utf-8 به windows-1256):
<meta content="text/html; charset=Windows-1256" http-equiv="Content-Type">
using System.IO;
using System.Text;
public static void SaveAs1256(string fileName)
{
string content = File.ReadAllText(fileName);
File.WriteAllText(fileName, content, Encoding.GetEncoding("windows-1256"));
}
ج) اصلاح فایل hhp پروژه خود
فایل hhp مربوط به html help work shop را باز کنید. (همان فایل پروژه ساخت راهنما)
اگر مثال قبل را دنبال کرده باشید، محتوای فایل آن چیزی شبیه به خطوط زیر خواهد بود:
[OPTIONS]
Compatibility=1.1 or later
Compiled file=test.chm
Contents file=Table of Contents.hhc
Default Window=win1
Default topic=page1.html
Display compile progress=No
Full-text search=Yes
Index file=Index.hhk
Language=0x429 Farsi
Title=راهنمای یک
[WINDOWS]
win1=,"Table of Contents.hhc","Index.hhk","page1.html","page1.html",,,,,0x3420,,0x304e,,,,,,2,,0
[FILES]
page1.html
page2.html
[INFOTYPES]
به قسمت options چند سطر زیر را اضافه کنید: (زبان فارسی و فونت تاهومای عربی)
Default Font=Tahoma,8,178
Language=0x429 Farsi
محض نمونه، کل وبلاگ جاری را به یک فایل chm تبدیل کرده‌ام که آن‌را از آدرس زیر می‌توانید دریافت نمائید:
دریافت فایل
برای آزمایش، یک عبارت فارسی را در آن جستجو نمائید.
پ.ن.
این راه حلی است که به نظر من رسیده و جواب داده. اگر شما با encoding های دیگر هم جواب گرفته‌اید (مشکل جستجوی فارسی حل شده) لطفا پیغام بگذارید. با تشکر.
نکته : توابع عملیاتی API در صورتیکه کار خود را بدرستی انجام ندهند مقدار صفر، در غیر این صورت مقدار غیر صفر را برمی‌گردانند.
()ShellAbout
با استفاده از این تابع API میتوان پنجره About ویندوز را باز کرد و همچنین میتوان در متن آن تغییراتی را اعمال کرد.
[DllImport("shell32.DLL")]
[DllImport("User32.DLL")]
public string Lpwindow { get; set; }
public IntPtr Hicon { get; set; }
public static extern int ShellAbout(IntPtr hwnd,string szApp,string szotherstuff,IntPtr hicon );
public static extern int FindWindow(string str,string lpwindow); طریقه استفاده از تابع فوق
private void btnbutton1_Click(object sender, EventArgs e)
{
var Window = (IntPtr)FindWindow(null, Lpwindow);
ShellAbout(Window, "===WINDOWS===", "HELLO", Hicon);
} () SetSuspendState
با استفاده از این تابع API میتوان سیستم را به حالت Hibernate برد.
[DllImport("powrprof.dll")]
public static extern int SetSuspendState(int hibernate,int forcecritical,int DisablewakeEvent); طریقه استفاده از تابع فوق
private void btnbutton1_Click(object sender, EventArgs e)
{
SetSuspendState(1, 0, 0);
} ()LockWorkStation
با اجرای
این تابع سیستم به حالت Lock میرود و کاربر برای استفاده از سیستم باید کلمه عبور را وارد کند.
[DllImport(“user32.DLL”)] public static extern int LockWorkStation();
طریقه استفاده از تابع فوق
private void btnbutton1_Click(object sender, EventArgs e)
{
LockWorkStation();
} ()FatalAppExit
در صورت اجرای این تابع برنامه یک پیغام خطا نمایش میدهد و بعد از بستن این پیام برنامه بسته می‌شود.
DllImport("kernel32.DLL")]
public static extern int FatalAppExit(int uAction,string ipmesseg); طریقه استفاده از تابع فوق
private void btnbutton1_Click(object sender, EventArgs e)
{
FatalAppExit(0, "ERROR PROGRAM");
} ()timeGetTime
این تابع مدت زمان روشن بودن سیستم را به میلی ثانیه برمیگرداند.
[DllImport("Winmm.DLL")]
public static extern long timeGetTime();
private void timer1_Tick(object sender, EventArgs e)
{
var sd = Convert.ToString(timeGetTime());
int i = Convert.ToInt32(sd.Substring(0, sd.Length - 3));
int m;
if (i < 60)
textBox1.Text = @"00:00:" + i;
else if (i >= 60 && i < 3600)
{
m = i / 60;
S = i % 60;
textBox1.Text = @"00:" + m + @":";
}
else
{
var h = i / 3600;
var mm = i % 3600;
if (mm > 59)
{
m = mm / 60;
S = mm % 60;
textBox1.Text = h + @":" + m.ToString(CultureInfo.InvariantCulture) + @":" + S;
}
else
{
textBox1.Text = h + @":00:" + mm;
}
}
} طریقه استفاده از تابع فوق
private void Form1_Load(object sender, EventArgs e)
{
timer1.Start();
}
فیلدهای استاتیکی که در سطح یک کلاس تعریف می‌شوند، برای نگهداری داده‌هایی به کار می‌روند که بین همه‌ی اشیاء ساخته شده‌ی از آن کلاس مشترک هستند. لذا برای دستیابی به آنها، نیاز به ساختن شیءای از آن کلاس نبوده و از طریق خود کلاس در دسترس خواهند بود. اما نکته‌ای در مورد فیلدهای استاتیک وجود دارد و آن هم ترتیب مقدار دهی به آنها است که در این مجال قصد دارم به آن بپردازم.
در یک کلاس همانطور که می‌توانیم متد استاتیک و یا پراپرتی استاتیک داشته باشیم، قادر هستیم فیلدهایی را نیز به صورت استاتیک تعریف نماییم. با نوشتن کلمه‌ی کلیدی Static قبل از فیلد یک کلاس، آن فیلد تبدیل به فیلدی استاتیک شده و از این پس این فیلد، متعلق به اشیاء ساخته شده‌ی از کلاس نیست و تنها از طریق خود کلاس میتوان به آن دست یافت. اگر فیلد استاتیک به صورت خصوصی (private) تعریف شود، تنها اعضای داخلی آن کلاس می‌توانند به آن دسترسی داشته باشند و آن را تغییر دهند؛ ولی اگر به صورت عمومی‌تری تعریف شود، هر نوعی که بتواند به آن دسترسی داشته باشد، می‌تواند مقدار آن را ببیند و تغییر دهد.
زمانیکه شما یک کلاس با فیلد استاتیک را تعریف می‌کنید باید مراقب ترتیب مقدار دهی آنها نیز باشید. به عنوان مثال کلاس زیر را در نظر بگیرید:
در نگاه اول شاید کد بالا بدون مشکل به نظر برسد؛ یعنی اگر بخواهیم از مقادیر این فیلدهای استاتیک استفاده کنیم، انتظار داریم فیلد MaxAttempts به مقدار 5، فیلد WarningAttempts به مقدار 2 و فیلد Threshold به تفاضل آنها یعنی 3 مقداردهی شده باشند. ولی اگر کد زیر را اجرا کنید خروجی متفاوتی را مشاهده خواهید کرد:
همانطور که در این خروجی مشاهده می‌کنید، مقدار فیلد Threshold به صفر مقداردهی شده است؛ در حالیکه ما انتظار عدد 2 را داشتیم.
دلیل این مقدار غیر منتظره را باید در سند مشخصات زبان سی شارپ ( C# Language Specification ) یافت. در سند مشخصات زبان سی شارپ، نحوه‌ی استفاده‌ی از این زبان و دستورات نحوی ( Syntax ) آن به صورت شفافی توضیح داده شده‌اند. این سند بیان می‌کند هیچ فیلد استاتیکی هرگز نباید بدون مقدار باشد؛ یعنی اگر قبل از مقدار دهی یک فیلد استاتیک بخواهیم به مقدار آن دسترسی داشته باشیم، به مقدار اولیه‌ی نوع آن فیلد، مقدار دهی خواهد شد. پس در مثال بالا چون فیلدهای MaxAttempts و WarningAttempts از نوع Integer هستند، مقدار پیش‌فرض صفر را خواهند گرفت. همچنین این سند بیان می‌کند که اگر در کلاسی چندین فیلد استاتیک تعریف شوند و آنها در چند سطر جداگانه مقداردهی شوند (همانند کاری که ما در مثال بالا انجام دادیم) بر طبق ترتیبی که عملیات مقداردهی به آنها انجام میگیرد، مقدار خواهند گرفت. یعنی وقتی که فیلد استاتیک Threshold مقدار دهی می‌شود، چون فیلدهای استاتیک MaxAttempts و WarningAttempts هنوز مقداردهی نشده‌اند، مقدار صفر می‌گیرند. پس در نتیجه‌ی فیلد Threshold هم مقدار صفر را میگیرد و چون ترتیب مقدار دهی نیز مهم است، مقدار آن با تغییر مقدار فیلدهای MaxAttempts و WarningAttempts تغیر نکرده و کماکان صفر باقی خواهد ماند و پس از آن در خط‌های بعدی، فیلدهای MaxAttempts و WarningAttempts مقدار می‌گیرند.
پس برای رفع این مشکل باید ترتیب مقداردهی فیلدها را به گونه‌ای تغییر داد که قبل از استفاده‌ی از آنها، مقدارشان معلوم باشد.
اینبار خروجی زیر حاصل می‌شود:
مشکلی که این راه حل دارد این است که کد خوانایی نیست و قابلیت نگهداری خوبی هم ندارد. از آنجایی ما توسعه دهندگان عادت به تغییر کدهای دیگران را داریم، قابل پیش بینی‌است که یک توسعه دهنده‌ی دیگر، ترتیب نوشتن فیلدهای استاتیک را مثلا به قصد اینکه بخواهد آنها را به ترتیب حروف الفبا مرتب کند، تغییر دهد که اینکار منجر به یک باگ خواهد شد. یک راه حل بهتر این است که مقداردهی آنها را از تعریف‌اشان جدا کرده و عملیات مقداردهی به آنها را در یک سازنده‌ی استاتیک قرار دهیم که در این صورت هم خروجی بالا را خواهیم داشت:
در یک کلاس همانطور که می‌توانیم متد استاتیک و یا پراپرتی استاتیک داشته باشیم، قادر هستیم فیلدهایی را نیز به صورت استاتیک تعریف نماییم. با نوشتن کلمه‌ی کلیدی Static قبل از فیلد یک کلاس، آن فیلد تبدیل به فیلدی استاتیک شده و از این پس این فیلد، متعلق به اشیاء ساخته شده‌ی از کلاس نیست و تنها از طریق خود کلاس میتوان به آن دست یافت. اگر فیلد استاتیک به صورت خصوصی (private) تعریف شود، تنها اعضای داخلی آن کلاس می‌توانند به آن دسترسی داشته باشند و آن را تغییر دهند؛ ولی اگر به صورت عمومی‌تری تعریف شود، هر نوعی که بتواند به آن دسترسی داشته باشد، می‌تواند مقدار آن را ببیند و تغییر دهد.
زمانیکه شما یک کلاس با فیلد استاتیک را تعریف می‌کنید باید مراقب ترتیب مقدار دهی آنها نیز باشید. به عنوان مثال کلاس زیر را در نظر بگیرید:
class AttemptController
{
internal static int Threshold = MaxAttempts - WarningAttempts;
internal static int MaxAttempts = 5;
internal static int WarningAttempts = 2;
} Console.WriteLine("Maximum: {0}", AttemptController.MaxAttempts);
Console.WriteLine("Warning: {0}", AttemptController.WarningAttempts);
Console.WriteLine("Threshold: {0}", AttemptController.Threshold);
/* OUTPUT
Maximum: 5
Warning: 2
Threshold: 0
*/ دلیل این مقدار غیر منتظره را باید در سند مشخصات زبان سی شارپ ( C# Language Specification ) یافت. در سند مشخصات زبان سی شارپ، نحوه‌ی استفاده‌ی از این زبان و دستورات نحوی ( Syntax ) آن به صورت شفافی توضیح داده شده‌اند. این سند بیان می‌کند هیچ فیلد استاتیکی هرگز نباید بدون مقدار باشد؛ یعنی اگر قبل از مقدار دهی یک فیلد استاتیک بخواهیم به مقدار آن دسترسی داشته باشیم، به مقدار اولیه‌ی نوع آن فیلد، مقدار دهی خواهد شد. پس در مثال بالا چون فیلدهای MaxAttempts و WarningAttempts از نوع Integer هستند، مقدار پیش‌فرض صفر را خواهند گرفت. همچنین این سند بیان می‌کند که اگر در کلاسی چندین فیلد استاتیک تعریف شوند و آنها در چند سطر جداگانه مقداردهی شوند (همانند کاری که ما در مثال بالا انجام دادیم) بر طبق ترتیبی که عملیات مقداردهی به آنها انجام میگیرد، مقدار خواهند گرفت. یعنی وقتی که فیلد استاتیک Threshold مقدار دهی می‌شود، چون فیلدهای استاتیک MaxAttempts و WarningAttempts هنوز مقداردهی نشده‌اند، مقدار صفر می‌گیرند. پس در نتیجه‌ی فیلد Threshold هم مقدار صفر را میگیرد و چون ترتیب مقدار دهی نیز مهم است، مقدار آن با تغییر مقدار فیلدهای MaxAttempts و WarningAttempts تغیر نکرده و کماکان صفر باقی خواهد ماند و پس از آن در خط‌های بعدی، فیلدهای MaxAttempts و WarningAttempts مقدار می‌گیرند.
پس برای رفع این مشکل باید ترتیب مقداردهی فیلدها را به گونه‌ای تغییر داد که قبل از استفاده‌ی از آنها، مقدارشان معلوم باشد.
class AttemptController
{
internal static int MaxAttempts = 5;
internal static int WarningAttempts = 2;
internal static int Threshold = MaxAttempts - WarningAttempts;
} Maximum: 5 Warning: 2 Threshold: 3
مشکلی که این راه حل دارد این است که کد خوانایی نیست و قابلیت نگهداری خوبی هم ندارد. از آنجایی ما توسعه دهندگان عادت به تغییر کدهای دیگران را داریم، قابل پیش بینی‌است که یک توسعه دهنده‌ی دیگر، ترتیب نوشتن فیلدهای استاتیک را مثلا به قصد اینکه بخواهد آنها را به ترتیب حروف الفبا مرتب کند، تغییر دهد که اینکار منجر به یک باگ خواهد شد. یک راه حل بهتر این است که مقداردهی آنها را از تعریف‌اشان جدا کرده و عملیات مقداردهی به آنها را در یک سازنده‌ی استاتیک قرار دهیم که در این صورت هم خروجی بالا را خواهیم داشت:
class AttemptController
{
internal static int MaxAttempts;
internal static int WarningAttempts;
internal static int Threshold;
static AttemptController()
{
MaxAttempts = 5;
WarningAttempts = 2;
Threshold = MaxAttempts - WarningAttempts;
}
}
عموما در اکثر مطالب مقایسه‌ای بین وب فرم‌ها و 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 این فیلتر را تنها میتوان بر روی یک فرم خاص عمومی برای مثال اعمال کرد و نه کل برنامه.
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 این فیلتر را تنها میتوان بر روی یک فرم خاص عمومی برای مثال اعمال کرد و نه کل برنامه.
یک نکته‌ی تکمیلی: اضافه شدن پارامترهای از نوع ref readonly به C# 12
در انتهای نکته‌ی خروجی ref readonly عنوان شد که «در ابتدا قصد داشتند ref readonly را برای تعریف پارامترهای value type نیز بکار برند، اما این تصمیم با معرفی پارامترهای از نوع in جایگزین شد» اما ... مجددا به C# 12 اضافه شده‌است:
مثال زیر را درنظر بگیرید:
در این مثال، ارجاعی از متغیر عددی number (که یک value type است) به کمک واژه‌ی کلیدی ref به متد Print ارسال شده و درون این متد، مقدار این متغیر تغییر کرده‌است که این تغییر به خارج از متد Print نیز منعکس می‌شود.
اگر بخواهیم از تغییرات پارامتر number در متد Print جلوگیری کنیم، میتوان از واژه‌ی کلیدی in که در C# 7.2 ارائه شد، استفاده کرد:
در این حالت در سطر ++number، به خطای زیر می‌رسیم:
اکنون در C# 12 همین عمل را توسط واژه‌های کلیدی ref readonly نیز میتوان پیاده سازی کرد:
خطایی را هم که گزارش میدهد، دقیقا همانند خطای ذکر شده‌ی واژه‌ی کلیدی in است.
سؤال: چرا این تغییر در C# 12 رخ داده‌است، زمانیکه واژه‌ی کلیدی in، دقیقا همین کار را انجام می‌داد؟
هدف، وضوح بیشتر API تولیدی و تاکید بر readonly بودن ارجاع دریافتی در این حالت و یکدستی قسمت‌های مختلف زبان است.
همچنین واقعیت این است که یک چنین قابلیت‌هایی، استفاده‌ی روزمره‌ای را در زبان #C ندارند و بیشتر هدف از وجود آنها، استفاده از API کتابخانه‌های C++/C در زبان #C است. برای مثال بجای اینکه تمام ارجاعات فقط خواندنی آنها را به پارامترهایی از نوع in تبدیل کنند (در کدهای قدیمی) که سبب بروز مشکلات عدم سازگاری می‌شود، اکنون می‌توانند به سادگی refهای قدیمی تعریف شده را ref readonly کنند؛ بدون اینکه استفاده کنندگان با مشکلی مواجه شوند.
در انتهای نکته‌ی خروجی ref readonly عنوان شد که «در ابتدا قصد داشتند ref readonly را برای تعریف پارامترهای value type نیز بکار برند، اما این تصمیم با معرفی پارامترهای از نوع in جایگزین شد» اما ... مجددا به C# 12 اضافه شده‌است:
مثال زیر را درنظر بگیرید:
namespace CS8Tests;
public class RefReadonlySample
{
public void Test()
{
var number = 5;
Print(ref number);
Console.WriteLine($"After Print -> Your number is {number}");
// Output:
// Print -> Your number is 5
// After Print -> Your number is 6
}
private void Print(ref int number)
{
Console.WriteLine($"Print -> Your number is {number}");
number++;
}
} اگر بخواهیم از تغییرات پارامتر number در متد Print جلوگیری کنیم، میتوان از واژه‌ی کلیدی in که در C# 7.2 ارائه شد، استفاده کرد:
private void Print(in int number)
error CS8331: Cannot assign to variable 'number' or use it as the right hand side of a ref assignment because it is a readonly variable
اکنون در C# 12 همین عمل را توسط واژه‌های کلیدی ref readonly نیز میتوان پیاده سازی کرد:
private void Print(ref readonly int number)
سؤال: چرا این تغییر در C# 12 رخ داده‌است، زمانیکه واژه‌ی کلیدی in، دقیقا همین کار را انجام می‌داد؟
هدف، وضوح بیشتر API تولیدی و تاکید بر readonly بودن ارجاع دریافتی در این حالت و یکدستی قسمت‌های مختلف زبان است.
همچنین واقعیت این است که یک چنین قابلیت‌هایی، استفاده‌ی روزمره‌ای را در زبان #C ندارند و بیشتر هدف از وجود آنها، استفاده از API کتابخانه‌های C++/C در زبان #C است. برای مثال بجای اینکه تمام ارجاعات فقط خواندنی آنها را به پارامترهایی از نوع in تبدیل کنند (در کدهای قدیمی) که سبب بروز مشکلات عدم سازگاری می‌شود، اکنون می‌توانند به سادگی refهای قدیمی تعریف شده را ref readonly کنند؛ بدون اینکه استفاده کنندگان با مشکلی مواجه شوند.
یعنی از مدیریت اطلاعات وابسته به زمان در بانک‌های اطلاعاتی رابطه‌ای استفاده نمی‌کنید؟ یعنی مثلا با تغییر قیمت یا تغییر نرخ حقوق یا مالیات این‌ها را مستقیما در SPها تغییر می‌دید و بعد سابقه اطلاعات قبلی بهم می‌ریزن؟
Debug.WriteLine در پنجره دیباگ ویژوال استودیو پیام‌ها را نمایش میدهد. اگر این پنجره را مشاهده نمی‌کنید این سطر را تبدیل به throw new Exception کنید تا واضح‌تر شود؛ یا روی آن یک break point قرار دهید و پیام‌ها را یکی یکی بررسی کنید.
بر اساس فصل بندی‌های کتاب Apress نوشته شده. به نظر من کتاب Apress جامع‌تر هست.
تمامی قابلیت‌های برجسته‌ی ASP.NET MVC 4 در این کتاب هست. اما هر چه بیشتر مطالعه کنید، ضرر نمی‌کنید.
تمامی قابلیت‌های برجسته‌ی ASP.NET MVC 4 در این کتاب هست. اما هر چه بیشتر مطالعه کنید، ضرر نمی‌کنید.