USE tempdb GO CREATE TABLE Customers1 ( ID INT IDENTITY,-- ID INT IDENTITY(1,1) Name NVARCHAR(100), [Address] NVARCHAR(200) ) GO
INSERT INTO Customers1 (Name,[Address]) VALUES (N'مسعود',N'میانه'), (N'فرید',N'میانه'), (N'احمد',N'میانه') GO SELECT * FROM Customers1
USE tempdb GO CREATE TABLE Customers2 ( ID INT IDENTITY(100,2), Name NVARCHAR(100), [Address] NVARCHAR(200) ) GO
INSERT INTO Customers2 (Name,[Address]) VALUES (N'مسعود',N'میانه'), (N'فرید',N'میانه'), (N'احمد',N'میانه') GO SELECT * FROM Customers2
Resource Governor، اجازه میدهد تا انواع مختلف Session را بر روی Server طبقه بندی کنید که به نوبه خود چگونگی کنترل تخصیص منابع سرور به فعالیت داده شده را به شما اعطا میکند. این قابلیت کمک میکند که ادامه فرآیندهای OLTP تضمین شود و یک عملکرد قابل پیش بینی فراهم میکند تا توسط فرآیندهای غیر قابل پیش بینی، تحت تاثیر منفی قرار نگیرد. با استفاده از Resource Governor، قادر خواهید بود نحوه دستیابی به Session را به منظور محدود کردن منابع خاص برای SQL Server مشخص کنید. به عنوان مثال میتوانید مشخص کنید که بیش از 20 درصد از پردازنده یا منابع حافظه به گزارشهای در حال اجرا اختصاص داده نشود. هنگامیکه این ویژگی فعال باشد، مهم نیست چه تعداد گزارش در حال اجرا است، آنها هرگز نمیتوانند از تخصیص منابع تعیین شده تجاوز کنند. البته این موضوع عملکرد گزارش گیری را کاهش میدهد ولی عملکرد فرآیندهای OLTP حداقل توسط گزارش ها، دیگر تحت تاثیر منفی قرار نمیگیرد.
1- بررسی اجمالی Resource Governor:
Resource Governor، با کنترل تخصیص منابع بر حسب Workload کار میکند. هنگامی که یک درخواست اتصال به موتور بانک اطلاعاتی ارسال میشود درخواست براساس یک تابع رده بندی (Classification function) طبقه بندی میشود. تابع رده بندی یک تابع اسکالر است که از طریق T-SQL تعریف میشود. تابع رده بندی، اطلاعات را درباره یک اتصال (برای مثال login ID، application name، hostname، server role ) ارزیابی میکند، به منظور تشخیص اینکه چگونه آنها را دسته بندی کند. پس از دسته بندی درخواست اتصال، آنها به گروههای حجم کاری (Workload Group) که برای رده بندی تعریف شده اند، شکسته میشوند. هر Workload Group مرتبط با یک مخزن منابع (Resource Pool) است.
یک Resource Pool، منابع فیزیکی SQL Server را نمایش میدهد (در حال حاضر در SQL Server 2008، تنها منابع فیزیکی موجود برای پیکربندی پردازنده و حافظه است) و مقدار حداکثر پردازنده و یا منابع حافظه را که به نوع خاصی از Workload اختصاص داده میشود، تعیین میکند. هنگامی که یک اتصال طبقه بندی شده و در Workload Group صحیح خود قرار میگیرد به این اتصال، پردازنده و منابع حافظه به اندازه نسبت داده شده به آن تخصیص داده میشود و سپس Query به Query Optimizer برای اجرا داده میشود.
2- اجزای Resource Governor:
Resource Governor، از سه قسمت اصلی تشکیل شده است: Classification، Workload Groups و Resource Pools. درک این سه قسمت و چگونگی تعامل آنها به درک و استفاده از Resource Governor کمک میکند.
2-1- Classification:
Classification، فرآیند ارزیابی اتصالات ورودی کاربر و اختصاص آن به یک Workload Group است که توسط منطق موجود در یک تابع تعریف شده توسط کاربر (user-defined function) انجام میشود. تابع نام یک Workload Group را برمی گرداند که Resource Governor از آن برای مسیر دهی Session به Workload Group مناسب استفاده میکند.
هنگامی که Resource Governor پیکربندی میشود فرآیند ورود به سیستم برای یک Session شامل گامهای زیر است:
• Login authentication2-2- Workload Groups:
• LOGON trigger execution
• Classification
Workload Groups، ظروفی برای اتصالات مشابه هستند که با توجه به معیارهای طبقه بندی برای هر اتصال گروه بندی میشوند. Workload Groups همچنین مکانیسمی برای تجمیع نظارت بر روی منابع مصرفی فراهم میکند.
Resource Governor دو Workload Group از پیش تعریف شده دارد: یک گروه داخلی (internal group) و یک گروه پیش فرض (default group).
Internal Workload Group، تنها توسط فرآیندهای داخلی موتور بانک اطلاعاتی استفاده میشود. معیارهای طبقه بندی را برای گروههای داخلی نمیتوانید تغییر دهید و همچنین هیچ یک از درخواستهای کاربران را برای انتقال به گروه داخلی نمیتوانید رده بندی کنید، با این حال بر گروه داخلی میتوانید نظارت کنید.
درخواستهای اتصال به طور خودکار هنگامی که شرایط زیر وجود دارد، به Default Workload Group رده بندی میشوند:
• معیاری برای طبقه بندی درخواست وجود ندارد.Resource Governor، در مجموع 20 عدد Workload Group را پشتیبانی میکند. از آنجائی که دو عدد از آنها برای Workload Groupهای داخلی و پیش فرض ذخیره شده اند در مجموع 18 عدد Workload Group تعریف شده توسط کاربر (user-defined) میتوان تعریف نمود.
• کوششی برای رده بندی درخواستی به گروهی که وجود ندارد.
• خرابی کلی Classification
2-3- Resource pools:
Resource Pool (مخزن منابع)، نشان دهنده تخصیص منابع فیزیکی به SQL Server است. یک Resource Pool از دو بخش تشکیل شده است:
• در بخش نخستین حداقل رزرو منابع را مشخص میکنیم، این بخش از مخزن منابع با مخازن دیگر همپوشانی نمیکند.در 2008 SQL Server مخزن منابع با تعیین حداقل و حداکثر تخصیص CPU و حداقل و حداکثر تخصیص حافظه تنظیم میگردد. با تنظیم حداقل، در دسترس بودن منبع از مخزن تضمین میشود. از آنجائی که در هر رزرو حداقل منابع تداخلی نمیتواند وجود داشته باشد، مجموع مقادیر حداقل در تمام مخازن از 100% کل منابع Server نمیتواند تجاوز کند.
• در بخش دیگر حداکثر ممکن رزرو منابع را برای مخزن مشخص میکنیم، تخصیص منابع با مخازن دیگر مشترک است.
مقدار حداکثر در محدوده بین حداقل و شامل 100% مقدار میتواند تنظیم گردد. تنظیم حداکثر نشان دهنده مقدار حداکثری است که یک Session میتواند مصرف کند، مادامی که منابع در دسترس باشند و توسط مخزن دیگر که با حداقل مقدار غیر صفر پیکربندی شده، استفاده نشود. هنگامی که یک مخزن با حداقل مقدار غیر صفر تعریف شده، مقدار حداکثر موثر از مخزنهای دیگر دوباره تنظیم میشوند، در صورت لزوم حداکثر مقدار موجود از جمع کل حداقل منابع مخازن دیگر کسر میگردد.
برای مثال، دو مخزن تعریف شده توسط کاربر (user-defined) را در نظر بگیرید. مخزن اول Pool1 با مقدار حداقل 20% و مقدار حداکثر 100% تعریف شده، مخزن دیگری Pool2 با مقدار حداقل 50% و مقدار حداکثر 70% تعریف شده است. حداکثر مقدار موثر برایPool1 برابر 50% است (100% منهای مقدار حداقل 50% مخزن Pool2) و حداکثر مقدار موثر برای Pool2، 70% است زیرا حداکثر مقداری است که پیکربندی شده است، گر چه 80% باقی میماند.
بخش مشترکی از مخزن (مقدارش بین مقدار حداقل و مقدار حداکثر موثر است) که برای تعیین مقدار منابع مورد استفاده است، توسط مخزن میتواند مصرف شود اگر منابعی موجود باشد و توسط مخازن دیگر مصرف نشده باشد. هنگامی که منابعی توسط یک مخزن مصرف میشوند، آنها به یک مخزن مشخص نسبت داده میشوند، به بیان دیگر اشتراکی نیستند تا زمانی که فرآیند در آن مخزن به اتمام برسد.
برای توضیح بیشتر یک سناریو که در آن سه مخزن تعریف شده توسط کاربر (user-defined) وجود دارد، را در نظر بگیرید:
PoolA با حداقل مقدار 10% و حداکثر مقدار 100% تعریف میشود.
PoolB با حداقل مقدار 35% و حداکثر مقدار 90% تعریف میشود.
PoolC با حداقل مقدار 30% و حداکثر مقدار 80% تعریف میشود.
مقدار موثر PoolA و مجموع در صد منابع به اشتراک گذاشته PoolA به شرح زیر محاسبه خواهد شد:
( حداکثر مقدار PoolA ) - ( حداقل مقدار PoolB ) - ( حداقل مقدار PoolC ) = ( حداکثر مقدار موثر PoolA )
(حداکثر مقدار موثر PoolA ) – ( حداقل مقدار PoolA ) = ( اشتراک PoolA )
جدول زیر مقدار حداکثر موثر و اشتراکی را برای هر مخزن در این پیکربندی نمایش میدهد:
Internal Pool، منابع مصرف شده توسط فرآیندهای داخلی موتور بانک اطلاعاتی را نشان میدهد. این مخزن تنها شامل گروههای داخلی است و به هیچ وجه قابل تغییر نیست. مخزن داخلی مقدار ثابت حداقل صفر و حداکثر 100% را دارد و مصرف منابع توسط مخزن داخلی، از طریق تنظیمات در هر مخزن دیگر محدود یا کاسته نمیشود.
به عبارت دیگر حداکثر مقدار موثر مخزن داخلی همیشه 100% است. هر workloads در مخزن داخلی برای عملکرد Server حیاتی در نظر گرفته میشود و Resource Governor در صورت لزوم اجازه میدهد تا مخازن داخلی 100% منابع موجود را مصرف کند حتی اگر به معنی نقض نیازمندیهای منابع از سایر مخازن باشد.
Default Pool، اولین مخزن تعریف شده کاربر است. قبل از هرگونه پیکربندی، Default Pool تنها حاوی Default group است. Default Pool نمیتواند ایجاد یا حذف شود اما میتواند تغییر کند. Default Pool علاوه بر Default group میتواند شامل گروههای تعریف شده توسط کاربر (user-defined) نیز باشد.
3- پیکر بندی Resource Governor :
پیکربندی Resource Governor شامل مراحل زیر است:
- فعال کردن Resource Governor3-1- فعال کردن Resource Governor
- ایجاد مخازن منابع (Resource Pools) تعریف شده توسط کاربر (user-defined)
- تعریف Workload Groups و نسبت دادن آن به مخازن
- ایجاد Classification function
- ثبت Classification function به Resource Governor
پیش از اینکه بتوانید یک Resource Pool را ایجاد کنید، نیاز است تا نخست Resource Governor را فعال کنید.
3-2- تعریف Resource Pool
ویژگیهای موجود برای یک Resource Pool عبارتند از:
Name، Minimum CPU %، Maximum CPU%، Min Memory%، Max Memory%
3-3- تعریف Workload Group
پس از اینکه Resource Pool را تعریف کردید، گام بعدی ایجاد یک Workload Group و اختصاص آن به Resource Pool مناسب است. چندین workgroup را میتوان به مخزن (Pool) یکسان نسبت داد اما یک workgroup را به چندین Resource Pool نمیتوان نسبت داد. خواص انتخابی موجود برای Workload Groups به شما اجازه میدهد سطح بهتری از کنترل را روی اجرای دستورات یک Workload Group تنظیم کنید. انتخابهای موجود عبارتند از:
3-3-1- Importance :
اهمیت نسبی (کم، متوسط یا بالا) Workload Group درون Resource Pool را تعیین میکند. اگر چندین Workload Group را در یک Resource Pool تعریف کنید این تنظیمات تعیین میکند که درخواستها در عرض یک Workload Group در اولویت بالاتر یا پائینتری از Workload Groupهای دیگر درون همان Resource Pool اجرا شوند، مقدار متوسط تنظیم پیش فرض است. در حال حاضر فاکتورهای وزنی برای هر تنظیم کم برابر 1، متوسط برابر3 و زیاد برابر 9 است. به این معنی که زمانبند به اجرای Sessionهای درون workgroup هائی با اهمیت بالا، سه برابر بیشتر از workgroupهای با اهمیت متوسط و نه برابر بیشتر از workgroupهای کم اهمیت، مبادرت خواهد کرد.
3-3-2- Maximum Request :
حداکثر تعداد درخواستهای همزمان که اجازه دارند در یک Workload Group اجرا شوند را مشخص میکند. تنظیم پیش فرض، صفر، تعداد نامحدود دستور را اجازه میدهد.
3-3-3- CPU Time :
حداکثر مقدار زمان پردازنده در ثانیه را مشخص میکند که یک درخواست درون Workload Group میتواند استفاده کند. تنظیم پیش فرض، صفر، به معنی نامحدود است.
3-3-4- Memory Grant %:
به صورت در صد، حداکثر مقدار اعطا حافظه برای اجرا (Execution grant memory)، که یک تک دستور از Resource Pool میتواند اخذ کند را مشخص میکند. این درصد نسبی است از مقدار حافظه ای که به Resource Pool نسبت داده میشود. محدوده مجاز مقادیر از 0 تا 100 است. تنظیم پیش فرض 25 است.
Execution grant memory، مقدار حافظه ای است که برای اجرای query استفاده میشود (نه برای Buffer کردن یا cache کردن) که میتواند صرفه نظر از Resource Pool یا Workload Group توسط تعدادی از Sessionها به اشتراک گذاشته شود. توجه شود که تنظیم این مقدار به صفر از اجرای عملیات Hash Join و دستورات مرتب سازی در Workload Groupهای تعریف شده توسط کاربر (user-defined)جلوگیری میکند. همچنین این مقدار توصیه نمیشود بیشتر از 70 باشد زیرا ممکن است Server قادر نباشد، اگر Queryهای همزمان در حال اجرا باشند، حافظه آزاد کافی اختصاص دهد.
3-3-5- Grant Time-out :
حداکثر زمان، به ثانیه، که یک query برای یک منبع منتظر میماند تا در دسترس شود را مشخص میکند. اگر منبع در دسترس نباشد، فرآیند ممکن است با یک خطای time-out مواجه شود. تنظیم پیش فرض، صفر، به معنی این است که سرور time-out را با استفاده از محاسبات داخلی بر مبنای هزینه پرس و جو ( query cost ) با تعیین حداکثر زمان برآورد میکند.
3-3-6- Degree of Parallelism :
حداکثر درجه موازی سازی (DOP) را برای پرس و جوهای موازی تعیین میکند. محدوده مجاز مقادیر از 0 تا 64 است. تنظیم پیش فرض، صفر، به معنی این است که فرآیندها از تنظیمات عمومی استفاده میکنند.
3-4- ایجاد یک Classification function
پس از تعریف Resource Pool و Workload Group، به یک Classification function نیاز است که شامل منطق ارزیابی اتصالات و نسبت دادن آنها به Workload Group مناسب است. Classification function برای هر اتصال Session جدید به SQL Server بکار میرود. هر Session در Workload Group نسبت داده شده به آن باقی میماند تا زمانی که به پایان برسد، مگر اینکه صراحتاً به یک گروه متفاوت دوباره نسبت داده شود. فقط یک Classification function فعال در هر زمان میتواند وجود داشته باشد. در صورت عدم تعریف شدن یا عدم فعال بودن Classification function همه اتصالات به Workload Group Default نسبت داده میشوند. Classification function یک نام workgroup که نوع آن SYSNAME است (که یک نام مستعار برای دیتا تایپ nvarchar 128 است.) برمی گرداند. اگر تابع تعریف شده مقدار 'NULL ،'Default یا نام گروهی که وجود ندارد را برگرداند، Session به Workload Group Default نسبت داده میشود. همچنین اگر به هر دلیلی تابع با موفقیت خاتمه نیابد Session به Workload Group Default نسبت داده میشود.
منطق Classification function معمولاً مبتنی بر ویژگیهای اتصال است و اغلب از طریق مقدار بازگشتی توابع سیستمی از قبیل:
()SUSER_NAME() ،SUSER_SNAME() ،IS_MEMBER() ،IS_SERVERROLEMEMBER() ،HOST_NAME و یا ()APP_NAME، نام Workload Group اتصال مشخص میشود. علاوه بر این توابع میتوانید از ویژگیهای توابع دیگر برای ساخت منطق رده بندی استفاده کنید. تابع ()LOGINPROPERTY شامل دو ویژگی (DefaultDatabase و DefaultLanguage) میباشد که میتواند برای Classification function استفاده شود. بعلاوه تابع ()CONNECTIONPROPERTY پروتکلها و دسترسی به نقل و انتقالات در شبکه، همچنین جزئیات طرح احراز هویت، Local IP address و TCP Port و Client’s IP Address را برای استفاده اتصالات فراهم میکند. برای مثال میتوانید برای یک اتصال، یک Workload Group نسبت دهید، مبتنی بر اینکه subnet یک اتصال ازکجا میآید.
نکته: اگر قصد دارید از هر یک از توابع ()HOST_NAME و یا ()APP_NAME در تابع رده بندی تان استفاده کنید، توجه داشته باشید این امکان وجود دارد مقادیر بازگردانده شده توسط این توابع توسط کاربران تغییر داده شوند، گر چه به طور کلی گرایش به استفاده از تابع ()APP_NAME برای رده بندی اتصالات بیشتر است.
4- بررسی نمونه ای از پیکربندی Resource Governor
برای سادگی، در این قسمت مثالی ارائه میشود که از تابع ()SUSER_NAME استفاده میکند: در گام نخست، دو Resource Pool ایجاد میشود ( ReportPool و OLTPPool )
می توان تابع ()WorkgroupClassifier را در محیط SSMS با اجرای دستور زیر برای Loginهای متفاوت تست نمود:
در ادامه دستور زیر برای پیکربندی تابع رده بندی به Resource Governor استفاده میشود:
5- اصلاح پیکربندی Resource Governor:
میتوانید درمحیط SSMS تنظیمات Resource Pool و Workload Group را تغییر دهید ( برای مثال حداکثر استفاده CPU برای یک Resource Pool و یا درجه اهمیت یک Workload Group). متناوباً میتوان از دستورات T-SQL استفاده نمود.
نکته: پس از اجرای دستورات ALTER RESOURCE POOL یا ALTER WORKLOAD GROUP، برای اعمال کردن تغییرات اجرای دستور ALTER RESOURCE GOVERNOR RECONFIGURE نیاز میباشد.
5-1- حذف Workload Group :
یک Workload Group را اگر هر نوع Session فعال نسبت داده شده به آن وجود داشته باشد، نمیتوان حذف نمود. اگر یک Workload Group شامل Sessionهای فعال باشد، حذف Workload Groupو یا جابجائی آن به یک Resource Pool متفاوت، هنگامی که دستور ALTER RESOURCE GOVERNOR RECONFIGURE برای اعمال نمودن تغییرات فراخوانی میشود، با خطا مواجه خواهد شد.
5-2- حذف Resource Pools:
یک Resource Pool را اگر هر نوع Workload Group نسبت داده شده به آن وجود داشته باشد، نمیتوان حذف نمود. نخست نیاز دارید Workload Group حذف شود و یا به Resource Pool دیگری جابجا گردد.
5-3- اصلاح Classification function:
اگر نیاز دارید تغییراتی در تابع رده بندی ایجاد نمائید، مهم است توجه داشته باشید که تابع رده بندی تا زمانی که مشخص شده (marked) برای Resource Governor است، نمیتوان آنرا حذف و یا تغییر داد. پیش از اینکه بتوان تابع رده بندی را اصلاح و یا حذف نمود نخست نیاز دارید Resource Governor را غیر فعال نمائید. متناوباً میتوان تابع رده بندی را جایگزین کرد با اجرای دستور ALTER RESOURCE GOVERNOR و فرستادن (passing) یک اسم متفاوت برای CLASSIFIER_FUNCTION،همچنین میتوان با اجرای دستور زیر تابع رده بندی جاری را غیر فعال نمود:
تابع رده بندی میتوان تعریف کرد که نام Workload Group را از جداول یک بانک اطلاعاتی جستجو کند به جای اینکه نام Workload Group به صورت hard-coding و مطابق با ضوابط درون تابع باشد. عملکرد، در موقع دسترسی به جدول برای جستجو کردن نام Workload Group، نباید تا حد زیادی تحت تاثیر قرار گیرد.
6- نظارت بر Resource Governor
با استفاده از Performance Monitor، events و (Dynamic Management View (DMV میتوان Workload Group و Resource Pool را نظارت (Monitor) کرد. دو شی Performance برای این کار موجود است: SQL Server:Workload Group Stats و SQL Server:Resource Pool Stats
شکل زیر مربوط به پیکر بندی مثال مورد نظرمان میباشد:
7- نتیجه گیری
Resource Governor چندین مزیت بالقوه ارائه میدهد، در درجه اول قابلیت اولویت بندی منابع Server برای کاربران و برنامههای کاربردی (applications) بحرانی، جلوگیری از “runaway” یا درخواستهای غیر منتظره ای که به شدت و بطور قابل توجهی روی کارائی Server تاثیر منفی میگذارند.
ضمناً Resource Governor چندین مشکل بالقوه نیز عرضه میکند، برای مثال پیکربندی اشتباه Resource Governor تنها به عملکرد کلی Server آسیب نمیرساند بلکه به طور بالقوه روی سرور قفل (Lock) میتواند ایجاد کند و نیاز به استفاده از اتصال اختصاصی Administrator برای متصل شدن به SQL Server به منظور اشکال یابی و رفع مشکل میباشد. بنابراین توصیه شده است که تنها در صورتی که DBA با تجربه ای هستید و درک خوب و آشنائی خوبی با Workload هائی که روی بانک اطلاعاتی اجرا میشوند دارید، Resource Governor را بکار برید. حتی در این صورت، ضروری است که پیکربندی تان را روی یک Server تستی پیش از اینکه روی محیط تولیدی بگسترانید، تست نمائید.
Resource Governor به عنوان یک ویژگی با نام تجاری جدید در SQL Server 2008، با تعدادی محدودیت همراه است که احتمالاً در نسخههای بعدی SQL Server حذف خواهد شد، از محدودیت های بارز :
- محدودیت منابع (Resource)، که به CPU و حافظه محدود میشوند. I/O Disk و منابع شبکه را در SQL Server 2008 نمیتوان محدود کرد.
- استفاده از منابع برای Reporting Service، Analysis Service و Integeration Service را نمیتوان محدود کرد . در این نسخه محدودیتهای منابع تنها روی هسته موتور بانک اطلاعاتی بکار برده میشود.
- محدودیتهای Resource Governor روی یک SQL Instance تعریف و بکار برده میشود.
ما میتوانیم بعد از ساخت جدول و انتشار مقداری داده در آن قیدهایی را ایجاد کنیم. بطور پیشفرض اگر شرط قید ما بر قرار بود قید به طور صحیح ساخته میشود و اگر شرط قید ما بر قرار نباشد قید با خطای conflict مواجه خواهد شد.
بطور کلی غیر فعال کردن قیدها کار درستی نیست. ولی در برخی مواقع برای تسریع در اجرای کد میتوانیم قید را غیر فعال کنیم. بطور مثال اگر یک میلیون داده قرار است در جدول درج شود و مطمئن هستیم که این دادهها جامعیت دادهها را حفظ میکنند آنگاه میتوانیم قید را برای تسریع در عمل درج بطور موفق غیر فعال کنیم.
فعال و غیر فعال کردن از طریق DDL
با غیر فعال کردن قیود دادهها را در وضعیت نامناسبی قرار میدهیم ولی همان طور که اشاره شد بطور موفق اشکالی پیش نخواهد آمد.
در ادامه ابتدا طریقه غیرفعال کردن و مجددا فعال کردن قیود را توسط دستور alter table نشان خواهم داد سپس به سراغ امکانات ویزاردی میرویم. ابتدا یک جدول تک ستونه ایجاد میکنیم:
CREATE TABLE testTable (column1 integer not null);
الان هیچ قیدی روی جدول لحاظ نشده است. پس هر داده که در رنج domain ستون باشد را میتوانیم درج کنیم. پس بطور نمونه این دادهها را درج میکنیم:
INSERT INTO testTable VALUES (-10), (0), (10), (20), (30), (40)
حالا تصمیم داریم قیدی روی ستون column1 بگذاریم که توسط آن تنها اعداد مثبت در جدول درج شوند. پس داریم:
ALTER TABLE testTable WITH CHECK ADD CONSTRAINT NoNegative CHECK (column1 > 0);
The ALTER TABLE statement conflicted with the CHECK constraint "NoNegative".
برای ساخت این قید روی این دادهها تنها راه استفاده از کلید واژههای WITH NOCHECK است یعنی:
ALTER TABLE testTable WITH NOCHECK ADD CONSTRAINT NoNegative CHECK (column1 > 0);
و اکنون سعی میکنیم یک مقدار منفی در جدول درج کنیم:
INSERT INTO testTable VALUES (-5) /* The INSERT statement conflicted with the CHECK constraint "NoNegative". */
اما قیدی که ساخته بودیم در جدول در حال اعمال شدن است. برای درج مقدار منفی باید غیر را غیر فعال کنیم.
ALTER TABLE TestTable NOCHECK CONSTRAINT NoNegative
و حالا مقدار منفی را درج میکنیم. و برای برگرداندن وضعیت NOCHECK به وضعیت CHECK باید از کلید واژههای WITH NOCHECK استفاده کنیم. چرا که داده هایی در جدول درج شده اند که قید مورد نظر ما را نقض میکنند.
ALTER TABLE TestTable WITH NOCHECK CHECK CONSTRAINT NoNegative
فعال و غیر فعال کردن از طریق design
در قسمت object explorer قید مورد نظر را پیدا کرده و روی آن راست کلیک کرده و گزینه Modify را انتخاب کنید. سپس در پنجره باز شده در قسمت Table Designer تغییرات مورد نظر خود را اعمال کنید.
آیا «بازی» هم مینویسید؟
کتابخانه Angular Material 6x
ASP.NET MVC #16
مدیریت خطاها در یک برنامه ASP.NET MVC
استفاده از فیلتر HandleError
یکی از فیلترهای توکار ASP.NET MVC به نام HandleError، میتواند کار هدایت کاربر را به یک صفحهی خطای عمومی، در حین بروز استثنایی در برنامه، انجام دهد. برای آزمایش آن یک برنامه خالی جدید ASP.NET MVC را آغاز کنید. سپس یک کنترلر جدید را با محتوای زیر به آن اضافه نمائید:
using System;
using System.Web.Mvc;
namespace MvcApplication13.Controllers
{
public class HomeController : Controller
{
[HandleError]
public ActionResult Index()
{
throw new InvalidOperationException();
return View();
}
}
}
در اینجا جهت آزمایش برنامه، به عمد یک استثنای دستی را صادر میکنیم. برای آزمایش برنامه هم نیاز است آنرا خارج از دیباگر VS.NET اجرا کرد (آدرس برنامه را مستقیما خارج از VS.NET در یک مرورگر وارد کنید). همچنین یک سطر زیر را نیز لازم است به فایل web.config برنامه اضافه نمائید:
<system.web>
<customErrors mode="On" />
اکنون اگر برنامه را خارج از مرورگر اجرا کنید، با توجه به استفاده از ویژگی HandleError و همچنین بروز یک استثنا در متد Index، خودبخود صفحه Views\Shared\Error.cshtml به کاربر نمایش داده خواهد شد. در غیراینصورت صفحه زرد رنگ پیش فرض خطای ASP.NET به کاربر نمایش داده میشود که محتوای آنها بیشتر برای برنامه نویسها مناسب است و نه کاربران نهایی سیستم.
اگر علاقمند باشید که این ویژگی به صورت خودکار به تمام متدهای کنترلرهای برنامه اعمال شود، کافی است یک سطر زیر را به متد Application_Start فایل Global.asax.cs اضافه نمائید:
GlobalFilters.Filters.Add(new HandleErrorAttribute());
البته نیازی به انجام اینکار نیست زیرا اگر به متد RegisterGlobalFilters فایل Global.asax.cs دقت کنیم، اینکار پیشتر توسط قالب پیش فرض VS.NET انجام شده است. فقط برای فعال سازی آن نیاز است تگ customErrors در فایل وب کانفیگ برنامه مقدار دهی و تنظیم شود.
استفاده از صفحه خطای سفارشی دیگری بجای فایل Error.cshtml
امکان تنظیم نمایش صفحه خطای سفارشی دیگری نیز وجود دارد. برای مثال استفاده از فایل Views\Shared\CustomErrorView.cshtml :
[HandleError(View = "CustomErrorView")]
استفاده از صفحات خطای متفاوت به ازای استثناهای مختلف
میتوان فیلتر HandleError را تنها به یک نوع استثنای خاص محدود کرد. همچنین امکان استفاده از چندین ویژگی HandleError برای یک متد نیز وجود دارد:
[HandleError(ExceptionType = typeof(NullReferenceException), View = "ErrorHandling")]
دسترسی به اطلاعات استثناء در صفحه نمایش خطاها
زمانیکه برنامه به صفحه خطا هدایت میشود، نوع Model آن System.Web.Mvc.HandleErrorInfo میباشد:
@model System.Web.Mvc.HandleErrorInfo
@{
ViewBag.Title = "DbError";
}
<h2>An Error Has Occurred</h2>
@if (Model != null)
{
<p>@Model.Exception.GetType().Name<br />
thrown in @Model.ControllerName @Model.ActionName</p>
}
البته این نکته را صرفا به عنوان اطلاعات عمومی در نظر داشته باشید. زیرا اگر قرار باشد مجددا اصل استثناء را نمایش دهیم، همان صفحه زرد رنگ ASP.NET شاید بهتر باشد.
استفاده از تگ customErrors در فایل Web.config برنامه
ویژگی حالت تگ customErrors در فایل web.config برنامه، سه مقدار را میتواند بپذیرد:
الف) Off : صفحه زرد رنگ معرفی خطای ASP.NET را به همراه تمام اطلاعات مرتبط با استثنای رخ داده نمایش میدهد.
ب) RemoteOnly : همان حالت الف است با این تفاوت که صفحه خطا را فقط در کامپیوتری که وب سرور بر روی آن نصب است نمایش خواهد داد.
ج) On : یک صفحه خطای سفارشی شده را نمایش میدهد.
بنابراین هیچگاه از حالت Off استفاده نکنید. زیرا خطاهای نمایش داده شده، علاوه بر برنامه نویس، برای مهاجم به یک سایت نیز بسیار دلپذیر است!
حالت RemoteOnly در زمان توسعه برنامه توصیه میشود.
حالت On حین توزیع برنامه باید بکارگرفته شود.
مدیریت خطاهای رخ داده خارج از MVC Pipeline
HandleErrorAttribute تنها استثناهای رخ داده داخل ASP.NET MVC Pipeline را مدیریت میکند (یا خطاهایی از نوع 500). اگر این نوع استثناها خارج از آن رخ دهند مثلا فایلی یافت نشود (خطای 404) و امثال آن، باید به روش زیر عمل کرد:
<customErrors mode="On" defaultRedirect="error">
<error statusCode="404" redirect="error/notfound" />
<error statusCode="403" redirect="error/forbidden" />
</customErrors>
در اینجا اگر فایلی یافت نشد، کاربر به کنترلری به نام error و متدی به نام notfound هدایت خواهد شد. بنابراین نیاز به کنترلر زیر وجود دارد؛ به علاوه به ازای هر متد هم یک View متناظر باید اضافه شود (کلیک راست روی نام متد و انتخاب گزینه افزودن View جدید).
using System.Web.Mvc;
namespace MvcApplication13.Controllers
{
public class ErrorController : Controller
{
public ActionResult Index()
{
return View();
}
public ActionResult NotFound()
{
return View();
}
public ActionResult Forbidden()
{
return View();
}
}
}
برای آزمایش این قسمت، برنامه را اجرا کرده و سپس مثلا آدرس غیرموجود http://localhost/xyz را وارد کنید.
استفاده از فیلتر HandleError اجباری نیست
در همین قسمت قبل پس از افزودن customErrors و defaultRedirect آن که به نام یک کنترلر اشاره میکند، کلیه فیلترهای HandleError اضافه شده به برنامه را حذف کنید. سپس برنامه را خارج از محیط VS.NET اجرا کنید. باز هم متد Index کنترلر Error اجرا خواهد شد. به عبارتی الزاما نیازی به استفاده از فیلتر HandleError نیست و به کمک مقدار دهی صحیح تگ customErrors، کار نمایش خودکار صفحه سفارشی خطاها به کاربر انجام خواهد شد.
البته بدیهی است که گزینههای نمایش یک View خاص به ازای استثنایی ویژه، یکی از مزیتهای استفاده از فیلتر HandleError میباشد که امکان تنظیم آن در فایل web.config وجود ندارد.
ثبت اطلاعات استثناهای رخ داده به کمک ELMAH
نمایش صفحهی خطای سفارشی به کاربر، یکی از موارد ضروری تمام برنامههای ASP.NET است، اما کافی نیست. ثبت اطلاعات جزئیات استثناهای رخ داده در طول زمان میتوانند به بالا بردن کیفیت برنامه به شدت کمک کنند. برای این منظور میتوان همانند سابق از متد Application_Error قابل تعریف در فایل Global.asax.cs کمک گرفت؛ اما با وجود افزونهای به نام ELMAH اینکار اتلاف وقت است و اصلا توصیه نمیشود. همچنین به کمک ELMAH میتوان مشکلات را تبدیل به ایمیلهای خودکار کرد یا از آنها فید RSS درست نمود.
برای دریافت ELMAH یا به سایت اصلی آن مراجعه نمائید و یا به کمک NuGet هم به سادگی قابل دریافت است. پس از دریافت، ارجاعی را به اسمبلی آن (Elmah.dll) اضافه نمائید. در ادامه فایل web.config برنامه را گشوده و چند سطر زیر را به آن در قسمت configuration اضافه کنید:
<configuration>
<configSections>
<sectionGroup name="elmah">
<section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah"/>
<section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah"/>
<section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah"/>
<section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah"/>
<section name="errorTweet" requirePermission="false" type="Elmah.ErrorTweetSectionHandler, Elmah"/>
</sectionGroup>
</configSections>
سپس ذیل قسمت appSettings، تنظیمات پروایدر ذخیره سازی اطلاعات آنرا وارد نمائید. مثلا در اینجا از فایلهای XML برای ذخیره سازی اطلاعات استفاده خواهد شد (که امنترین حالت ممکن است؛ از این لحاظ که اگر بانک اطلاعاتی را انتخاب کنید، ممکن است مشکل اصلی از همانجا ناشی شده باشد. بنابراین خطایی ثبت نخواهد شد. همچنین در این حالت نیازی به سایر DLLهای همراه ELMAH هم نیست). در اینجا مسیر ذخیره سازی اطلاعات در پوشه app_data/errorslog تنظیم شده است:
<elmah>
<security allowRemoteAccess="1"/>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data/ErrorsLog"/>
</elmah>
در ادامه در قسمت system.web، دو تعریف زیر را اضافه نمائید. به این ترتیب امکان دسترسی به آدرس http://server/elmah.axd مهیا میگردد:
<httpModules>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
</httpModules>
<httpHandlers>
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/>
</httpHandlers>
البته برای IIS7 تنظیمات ذیل نیز باید اضافه شوند:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true">
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
</modules>
<handlers>
<add name="Elmah" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/>
</handlers>
</system.webServer>
و به این ترتیب تنظیمات اولیه ELMAH به پایان میرسد (و با ASP.NET Web forms هیچ تفاوتی ندارد).
مرحله بعد، تنظیمات مسیریابی ASP.NET MVC است برای اینکه آدرس http://server/elmah.axd را وارد سیستم پردازشی خود نکند. البته اینکار پیشتر انجام شده است:
public static void RegisterRoutes(RouteCollection routes)
{
//routes.IgnoreRoute("elmah.axd");
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
بنابراین همین تنظیمات، به همراه قالب پیش فرض یک پروژه جدید ASP.NET MVC برای استفاده از ELMAH کفایت میکند. اکنون پروژه جاری را یکبار دیگر خارج از VS.NET اجرا کرده و سپس به مسیر http://localhost/elmah.axd جهت مشاهده خطاهای لاگ شده به همراه جزئیات کامل آنها مراجعه کنید.
مشکل: استثناهای برنامه توسط ELMAH لاگ نمیشوند!
فیلتر HandleError با ELMAH سازگار نیست. زیرا با استفاده از آن، متدهای کنترلرها به صورت خودکار داخل یک try/catch اجرا شده و به این ترتیب استثناهای رخ داده، مدیریت گردیده و به ELMAH هدایت نمیشوند. بنابراین نیاز است به متد RegisterGlobalFilters فایل Global.asax.cs مراجعه کرده و سطر زیر را حذف کنید:
filters.Add(new HandleErrorAttribute());
و یا اگر قصد نداشتید اینکار را انجام دهید، میتوان به نحو زیر نیز مشکل را حل کرد:
using System.Web.Mvc;
using Elmah;
namespace MvcApplication13.CustomFilters
{
public class ElmahHandledErrorLoggerFilter : IExceptionFilter
{
public void OnException(ExceptionContext context)
{
if (context.ExceptionHandled)
ErrorSignal.FromCurrentContext().Raise(context.Exception);
// all other exceptions will be caught by ELMAH anyway
}
}
}
در اینجا یک فیلتر سفارشی به برنامه اضافه شده است تا خطاهای مدیریت شده برنامه (خطاهای مدیریت شده توسط فیلتر HandleError توکار) را به موتور ELMAH هدایت کند. سایر خطاهای مدیریت نشده به صورت خودکار توسط ELMAH ثبت خواهند شد و نیازی به انجام کار اضافی در این مورد نیست.
سپس این فیلتر جدید را به صورت سراسری تعریف کنید:
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new ElmahHandledErrorLoggerFilter());
filters.Add(new HandleErrorAttribute());
}
ترتیب اینها هم مهم است. ابتدا باید ElmahHandledErrorLoggerFilter معرفی شود.
تذکر مهم!
حین استفاده از ELMAH یک نکته را فراموش نکنید:
اگر allowRemoteAccess آنرا به عدد 1 تنظیم کردهاید، به هیچ عنوان از نام پیش فرض elmah.axd استفاده نکنید (هر نام اختیاری دیگری را که علاقمند بودید و به سادگی قابل حدس زدن نبود، در فایل web.config وارد کنید).
خلاصه بحث
1- در ASP.NET MVC نیازی نیست تا متدهای کنترلرها را با try/catch شلوغ کنید.
2- حتما قسمت customErrors فایل وب کانفیگ برنامه را دهی کنید (این مورد را به چک لیست اجباری تهیه یک برنامه ASP.NET MVC اضافه کنید).
3- استفاده از فیلتر HandleError اختیاری است. اگر از قابلیت فیلتر کردن استثناهای ویژه آن استفاده نمیکنید، مقدار دهی customErrors وب کانفیگ برنامه هم همان کار را انجام میدهد.
4- برای ثبت جزئیات دقیق استثناهای رخ داده در برنامه، از ELMAH استفاده کنید و بیجهت وقت خودتان را صرف بازنویسی این افزونه ارزشمند نکنید.
مطالب مشابه
معرفی ELMAH
ثبت استثناهای مدیریت شده توسط ELMAH
نصب کامپوننت Blazored TextEditor
ابتدا نیاز است بستهی نیوگت آنرا با اجرای دستور زیر، به پروژهی Blazor خود اضافه کرد:
dotnet add package Blazored.TextEditor
libman install quill --provider unpkg --destination wwwroot/lib/quill
<head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>BlazorServer.App</title> <base href="~/" /> <link href="lib/quill/dist/quill.snow.css" rel="stylesheet" /> <link href="lib/quill/dist/quill.bubble.css" rel="stylesheet" />
<script src="lib/quill/dist/quill.min.js"></script> <script src="_content/Blazored.TextEditor/quill-blot-formatter.min.js"></script> <script src="_content/Blazored.TextEditor/Blazored-BlazorQuill.js"></script> <script src="_framework/blazor.server.js"></script> </body>
و در آخر جهت سهولت کار با این کامپوننت میتوان فضای نام آنرا به فایل BlazorServer.App\_Imports.razor به صورت زیر اضافه کرد:
@using Blazored.TextEditor
استفاده از کامپوننت Blazored.TextEditor در کامپوننت HotelRoomUpsert.razor
میخواهیم در کامپوننت HotelRoomUpsert.razor مثال این سری، بجای کامپوننت InputTextArea مورد استفاده، از یک HTML Editor استفاده کنیم:
<div class="form-group"> <label>Details</label> @*<InputTextArea @bind-Value="HotelRoomModel.Details" class="form-control"></InputTextArea>*@ <BlazoredTextEditor @ref="@QuillHtml"> <ToolbarContent> <select class="ql-header"> <option selected=""></option> <option value="1"></option> <option value="2"></option> <option value="3"></option> <option value="4"></option> <option value="5"></option> </select> <span class="ql-formats"> <button class="ql-bold"></button> <button class="ql-italic"></button> <button class="ql-underline"></button> <button class="ql-strike"></button> </span> <span class="ql-formats"> <select class="ql-color"></select> <select class="ql-background"></select> </span> <span class="ql-formats"> <button class="ql-list" value="ordered"></button> <button class="ql-list" value="bullet"></button> </span> <span class="ql-formats"> <button class="ql-link"></button> </span> </ToolbarContent> <EditorContent> </EditorContent> </BlazoredTextEditor> </div>
- همانطور که ملاحظه میکنید، این تعریف به همراه یک ارجاع به وهلهای از آن نیز هست:
<BlazoredTextEditor @ref="@QuillHtml">
@code { private BlazoredTextEditor QuillHtml;
برای تغییر اندازه و مقدار placeholder پیشفرض آن، میتوان به صورت زیر عمل کرد:
<div class="form-group pb-4" style="height:250px;"> <label>Details</label> <BlazoredTextEditor @ref="@QuillHtml" Placeholder="Please enter the room's detail">
تنظیم و دریافت متن نمایشی HTML Editor
مطابق مستندات این کامپوننت، روش تنظیم متن نمایشی آن، به کمک متد LoadHTMLContent است. به همین جهت متد زیر را به کدهای کامپوننت جاری اضافه میکنیم:
private async Task SetHTMLAsync() { if(!string.IsNullOrEmpty(HotelRoomModel.Details)) { await QuillHtml.LoadHTMLContent(HotelRoomModel.Details); } }
protected override async Task OnInitializedAsync() { if (Id.HasValue) { // Update Mode Title = "Update"; HotelRoomModel = await HotelRoomService.GetHotelRoomAsync(Id.Value); await SetHTMLAsync(); } // ... }
private async Task HandleHotelRoomUpsert() { // ... // Create Mode HotelRoomModel.Details = await QuillHtml.GetHTML(); // ... }
مشکل! ادیتور در زمان ویرایش یک رکورد، اطلاعات پیشین را نمایش نمیدهد!
پس از اعمال تغییرات فوق، برنامه را اجرا میکنیم. سپس یک اتاق جدید را اضافه کرده و در لیست نمایش اتاقها، گزینهی ویرایش آنرا انتخاب میکنیم. در این حالت هرچند کار مقدار دهی HotelRoomModel.Details در زمان ثبت اطلاعات انجام شده، اما ... در زمان ویرایش چیزی نمایش داده نمیشود و تغییراتی را که به متد رویدادگردان OnInitializedAsync اضافه کردهایم، عمل نمیکنند.
در این مورد در قسمت بررسی چرخهی حیات کامپوننتها توضیحاتی ابتدایی ارائه شد:
«رویدادهای OnAfterRender و OnAfterRenderAsync
پس از هر بار رندر کامپوننت، این متدها فراخوانی میشوند. در این مرحله کار بارگذاری کامپوننت، دریافت اطلاعات و نمایش آنها به پایان رسیدهاست. یکی از کاربردهای آن، آغاز کامپوننتهای جاوا اسکریپتی است که برای کار، نیاز به DOM را دارند؛ مانند نمایش یک modal بوت استرپی.»
بنابراین در این حالت خاص که ادیتور جاوا اسکریپتی مورد استفاده، پس از رندر کامل UI نمایش داده میشود، قرار دادن متد SetHTML در روال رویدادگردان OnInitializedAsync کار نخواهد کرد و باید آنرا به روال رویدادگردان OnAfterRender انتقال دهیم:
protected override async Task OnAfterRenderAsync(bool firstRender) { await SetHTMLAsync(); }
private async Task SetHTMLAsync() { if(!string.IsNullOrEmpty(HotelRoomModel.Details)) { await QuillHtml.LoadHTMLContent(HotelRoomModel.Details); StateHasChanged(); } }
مشکل! اگر در این حالت سعی کنیم متنی را در ادیتور وارد کنیم، میسر نیست و همچنین CPU Usage سیستم به 100 درصد رسیدهاست!
علت اینجا است که فراخوانی StateHasChanged، هر چند سبب رندر مجدد UI میشود، اما چون در پایان کار رندر قرار داریم، یک حلقهی بینهایت را سبب خواهد شد. به همین جهت باید در متد OnAfterRenderAsync، بر اساس پارامتر firstRender، از رندرهای بعدی جلوگیری کرد:
protected override async Task OnAfterRenderAsync(bool firstRender) { if (!firstRender) { return; } while (true) { try { await SetHTMLAsync(); break; } catch { await Task.Delay(100); // Quill needs some time to load } } }
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-20.zip
نکته : آشنایی با کد نویسی و مفاهیم #F برای درک بهتر مطالب توصیه میشود.
معرفی پروژه FSharpX
این قسمتها عبارتند از :
FSharpx.Core : شامل مجموعه ای کامل از توابع عمومی، پرکاربرد و ساختاری است که برای این زبان توسعه داده شده اند و با تمام زبانهای دات نت سازگاری دارند؛
FSharpx.Http : استفاده از #F در برنامه نویسی مدل Http؛
FSharpx.TypeProvider : این پروژه خود شامل چندین بخش است که در این جا چند مورد از آنها را عنوان میکنم:
- FSharpx.TypeProviders.AppSetting : متد خواندن و نوشتن (setter و getter) را برای فایلهای تنظیمان پروژه (Application Setting File) فراهم میکند.
- FSharpx.TypeProviders.Vector : برای محاسبات با ساختارهای برداری استفاده میشود.
- FSharpx.TypeProviders.Machine : برای دسترسی و اعمال تغییرات در رجیستری و فایلهای سیستمی استفاده میشود.
- FSharpx.TypeProviders.Xaml : با استفاده از این افزونه میتوانیم از فایلهای Xaml، در پروژههای #F استفاده کنیم و WPF Designer نرم افزار VS.Net هم برای این زبان قابل استفاده خواهد شد.
- FSharpx.TypeProviders.Regex : امکان استفاده از عبارات با قاعده را در این پروژه فراهم میکند.
یک مثال از عبارات با قاعده:
type PhoneRegex = Regex< @"(?<AreaCode>^\d{3})-(?<PhoneNumber>\d{3}-\d{4}$)"> PhoneRegex.IsMatch "425-123-2345" |> should equal true PhoneRegex().Match("425-123-2345").CompleteMatch.Value |> should equal "425-123-2345" PhoneRegex().Match("425-123-2345").PhoneNumber.Value |> should equal "123-2345"
ایتدا یک پروژه از نوع F# Console Application ایجاد کنید. از قسمت Project Properties (بر روی پروژه کلیک راست کنید و گزینه Properties را انتخاب کنید) نوع پروژه را به Windows Application تغییر دهید(قسمت Out Put Type). اسمبلیهای زیر را به پروژه ارجاع دهید:
- PresentationCore
- PresentationFramework
- WindowBase
- System.Xaml
با استفاده از پنجره Package Manager Console دستور نصب زیر را اجرا کنید(آخرین نسخه این پکیج 1.8.31 و حجم آن کمتر از یک مگابایت است):
PM> Install-Package FSharpx.TypeProviders.Xaml
حال یک فایل Xaml به پروژه اضافه کنید و کدهای زیر را در آن کپی کنید:
<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="WPF F# Sample By Masoud Pakdel" Height="350" Width="525"> <Grid Name="MainGrid"> <StackPanel Name="StackPanel1" Margin="50"> <Button Name="Button1">Who are you?</Button> </StackPanel> </Grid> </Window>
open System open System.Windows open System.Windows.Controls open FSharpx type MainWindow = XAML<"MainWindow.xaml"> let loadWindow() = let window = MainWindow() window.Button1.Click.Add(fun _ -> MessageBox.Show("Masoud Pakdel") |> ignore) window.Root [<STAThread>] (new Application()).Run(loadWindow()) |> ignore
در تابع loadWindow یک نمونه از کلاس MainWindow ساخته میشود و برای button1 آن رویداد کلیک تعریف میکنیم. دستورات زیر معادل دستورات شروع برنامه در فایل program پروژههای #C است.
[<STAThread>] (new Application()).Run(loadWindow()) |> ignore
پروژه را اجرا کنید و بر روی تنهای Button موجود در صفحه، کلیک کنید و پیغام مورد نظر را مشاهده خواهید کرد. به صورت زیر: