وحید نصیری وحید نصیری
مطالب
خلاصه‌ای کوتاه در مورد WinRT

WinRT چیست؟

مایکروسافت جهت سهولت تولید برنامه‌های جدید Metro-style ، لمسی (touch-centric) و tablets ویندوز 8 ، اقدام به بازنویسی مجدد Windows-API کرده و نام آن‌را WinRT گذاشته است. بنابراین همانند آنچه که در مورد API‌ ویندوز از روز اول پیدایش آن مرسوم بوده، این API جدید، از نوع native (نوشته شده با CPP) می‌باشد و با کمک دات نت فریم ورک تهیه نشده است. این API جدید مبتنی بر فناوری قدیمی COM است، بنابراین مطابق معمول توسط هر نوع برنامه‌ و سیستمی در ویندوز قابل دسترسی است. تفاوتی نمی‌کند که CPP یا دلفی باشد یا دات نت. به صورت خلاصه ویندوز 8 دو طراحی جدید (WinRT) و قدیم (Win32 API) را با هم پشتیبانی می‌کند. اگر آن‌را صحیح‌تر بخواهیم معرفی کنیم، WinRT درحقیقت محصور کننده‌ی (Wrapper) همان Win32 API سابق است (در پشت صحنه همان dll های سابق ویندوز را بارگذاری و استفاده می‌کند) جهت تطابق با نیازهای دهه اخیر و سال‌های پیش رو.


سازگاری دات نت فریم ورک با WinRT چگونه است؟

اینبار WinRT برخلاف Win32 API (که در زمان ارائه آن اصلا دات نتی در کار نبود)، جهت سازگاری با دات نت طراحی شده است. این طراحی جدید ILDasm metadata را در اختیار برنامه نویس‌های دات نت قرار می‌دهد و به این ترتیب IntelliSense و قابلیت‌های Debugging ویژوال استودیو همانند کدهای مدیریت شده‌ی دات نت جهت برنامه نویسی مبتنی بر WinRT در اختیار برنامه نویس‌ها خواهد بود (فرمت ارائه شده، ECMA 335 metadata format می‌باشد). همچنین اشیاء COM متعلق به WinRT به خوبی توسط GC (آشغال جمع کن) دات نت جهت مدیریت بهتر حافظه، تحت نظر می‌باشند.
بنابراین از دیدگاه یک برنامه نویس دات نت، کل WinRT به صورت managed assemblies مشاهده می‌شود، اینترفیس‌های آن همان اینترفیس‌های دات نتی خواهند بود و کلاس‌های آن نیز به همین ترتیب. این مشکلی بود/هست که با Win32 API در دات نت وجود دارد و دسترسی به آن به این سادگی و یکپارچگی میسر نیست (هر چند تا الان کل اینترفیس آن جهت استفاده در دات نت نیز ترجمه شده است). در اینجا شما ارجاعاتی را به فایل‌هایی با پسوند winmd یا windows metadata، به پروژه‌ی دات نتی خود اضافه می‌کنید و سپس CLR قادر خواهد بود تا کلیه اطلاعات لازم جهت کار با WinRT را از آن‌ها استخراج کند (این فایل‌ها در پوشه C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata و C:\Windows\system32\winmetadat ویندوز 8 قابل مشاهده و دسترسی هستند).


تفاوت‌های مهم امکانات نمایشی WinRT با Win32 API کدامند؟

تفاوت مهم WinRT با Win32 API از دیدگاه برنامه نویس‌ها، امکان دسترسی بیشتر به آن از طریق زبان‌های مختلف می‌باشد. WinRT همانند Win32 API توسط CPP ، دات نت و سایر روش‌های مرسوم دیگر قابل دسترسی و توسعه است. اما اینبار WinRT برخلاف Win32 API ، از طریق HTML و جاوا اسکریپت هم قابل توسعه است. در این حالت کدهای شما توسط Chakra JavaScript engine که از اینترنت اکسپلورر 9 به بعد ارائه شده، اجرا خواهد شد. بنابراین «برفراز» WinRT دو لایه نمایشی (presentation layer) قابل طراحی و دسترسی است. XAML و زبان‌های متداول برنامه نویسی موجود مانند سی شارپ و وی بی دات نت و غیره. همچنین HTML/CSS هم مجال ابراز وجود یافته است. البته XAML تنها لایه نمایشی کلیه زبان‌های قدیمی موجود مانند سی شارپ، وی بی دات نت، CPP و غیره خواهد بود. به همین جهت Expression Blend جدید نیز از HTML 5 پشتیبانی می‌کند.
همچنین در WinRT ، قسمت‌های GDI و Message loop متداول Win32 API حذف شده است و از DirectX استفاده می‌کند. برای نمونه کدهای XAML شما توسط DirectX رندر می‌شود. البته این مطلب جدیدی نیست و از زمان ارائه WPF شاهد این مساله بوده‌ایم.


وضعیت توسعه پذیری WinRT  چگونه است؟

علاوه بر این‌ها، برخلاف Win32 API ، اینبار WinRT قابل توسعه است و Extensions SDK برای آن ارائه شده است.


آیا WinRT شاهد تغییرات امنیتی خاصی هم بوده است؟

نکته‌ی مهمی که در طراحی WinRT به آن توجه شده است، امنیت می‌باشد. برنامه‌های WinRT شبیه به برنامه‌های سیلورلایت در یک Sandbox اجرا می‌شوند. به این معنا که جهت ذخیره سازی اطلاعات خود از یک isolated storage استفاده می‌کنند. برای کار با file system نیاز به تائید کاربر دارند و خلاصه دیگر به سادگی نمی‌توان از مرزهای این نوع برنامه‌ها رد شد و سیستم عاملی را root کرد. برای نمونه برنامه نویس‌های دات نت دسترسی به فضای نام System.IO.FileStream را دیگر نخواهند داشت و تنها قسمتی از دات نت «برفراز» WinRT و مدل امنیتی جدید آن معنا پیدا می‌کند. همچنین برفراز این API جدید، تولید مثلا Device drivers هم دیگر معنا پیدا نمی‌کند. این محدودیت‌های امنیتی برای برنامه‌ نویس‌های native هم وجود دارد و تفاوتی نمی‌کند. کلا برنامه‌های جدید Metro-style در یک قرنطینه‌ی کامل امنیتی اجرا می‌شوند. برای مثال اگر برنامه‌ای نیاز به دسترسی به یک WebCam را داشته باشد، همانند برنامه‌های سیلورلایت ابتدا باید کاربر تائید کرده و سپس برنامه مجوز امنیتی کار با مثلا یک WebCam را خواهد یافت. همچنین تمام برنامه‌های جدید Metro-style باید جهت ارائه در فروشگاه جدید ویندوز 8، دارای امضای دیجیتال معتبر نیز باشند.


آیا جهت توسعه‌ی برنامه‌های چندریسمانی و غیرهمزمان تمهیدات خاصی در WinRT پیش‌بینی شده است؟

در طراحی جدید WinRT به اعمال asynchronous به شدت توجه شده است. هر عملی که بیش از 50 میلی ثانیه طول بکشد به صورت خودکار تبدیل به یک عمل asynchronous خواهد شد تا برنامه‌ها مرتبا در حین اجرای اعمال زمانبر هنگ نکرده و ترد اصلی برنامه را بلاک نکنند. علاوه بر این‌ها WinRT از طریق IAsyncOperation interface خود، امکان استفاده از واژه‌های جدید کلیدی async/await سی شارپ 5 را نیز مهیا می‌سازد.


آیا WinRT آمده است تا جایگزینی برای دات نت و سیلورلایت و امثال آن باشد؟

خیر. WinRT نگارش دوم Win32 API است با هدف توسعه پذیری، استفاده از دایرکت ایکس و فناوری‌های جدید که عموما از شتاب دهنده‌های سخت افزاری هم بهره‌مند هستند بجای GDI سابق، استفاده ساده‌تر در زبان‌های دیگر به کمک فایل‌های استاندارد Windows Meta data آن می‌باشد. همچنین این API جدید دسترسی به امکانات ویندوز را هم توسط HTML و جاوا اسکریپت، علاوه بر امکانات مهیای سابق میسر ساخته است. هم اکنون نگارش 4 و نیم دات نت در ویندوز 8 ارائه شده است و توسط هر دو سیستم سابق و جدید قابل استفاده می‌باشد. البته باید در نظر داشت که جهت استفاده از WinRT به دلایل محدودیت‌های امنیتی اعمال شده به آن و همچنین استفاده از XAML به تنها عنوان لایه نمایشی سیستم‌های متداول غیر HTML ایی، دات نت فریم ورک به امکانات و کلاس‌های کمتری نسبت به حالت متداول کار با آن، دسترسی دارد (جهت درک بهتر این محدودیت‌ها می‌توان به طراحی سیلورلایت مراجعه کرد). این را هم باید اضافه کرد که ویندوز 8 توانایی اجرای هر دو نوع برنامه‌های سبک جدید مترو و متداول دسکتاپ قدیمی را دارا است.


جهت آشنایی بیشتر با WinRT می‌توان به مجموعه‌ای از ویدیوهای مرتبط آن مراجعه کرد:
http://channel9.msdn.com/Events/BUILD/BUILD2011?t=windows%2Bruntime


‫۱۳ سال و ۲ ماه قبل، سه‌شنبه ۲۹ شهریور ۱۳۹۰، ساعت ۱۵:۱۴
توسعه چابک توسعه چابک
مطالب
چرا توسعه چابک (Agile Development)؟

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

همین که با شکستی مواجه می­شویم از تکرار چنین پروژه هایی اجتناب می­کنیم. ترس ما باعث می­شود تا فرآیندی بسازیم که فعالیت­های ما را محدود نموده و ایجاد آرتیفکت­ها[۱] را الزامی کند. در پروژه­ جدید از  چیزهایی که در پروژه‌های قبلی به خوبی کار کرده­اند، استفاده می­کنیم. انتظار ما این است که آنها برای پروژه جدید نیز به همان خوبی کار کند.

اما پروژه‌­ها آنقدر ساده نیستند که تعدادی محدودیت و آرتیفکت­ ما را از خطاها ایمن سازند. با بروز خطاهای جدید ما آنها را شناسایی و رفع می­کنیم. برای اینکه در آینده با این خطاها روبرو نشویم آنها را در محدودیت­ها و آرتیفکت­های جدیدی قرار می­دهیم. بعد از انجام پروژه‌های زیاد با فرآیندهای حجیم و پر زحمتی روبرو هستیم که توانایی تیم را کم کرده و باعث کاهش کیفیت تولید می­شوند.

فرآیندهای بزرگ و حجیم می­تواند مشکلات زیادی را ایجاد کند. متاسفانه این مشکلات باعث می­شود که خیلی از افراد فکر کنند که علت مشکلات، نبود فرآیندهای کافی است. بنابراین فرآیندها را حجیم­تر و پیچیده­تر می­کنند. این مسئله منجر به تورم فرآیندها می­گردد که در محدوده سال ۲۰۰۰ گریبان بسیاری از شرکت­های نرم افزاری را گرفت.

اتحاد چابک

در وضعیتی که تیم­های نرم افزاری در بسیاری از شرکت­ها خود را در مردابی از فرآیندهای زیاد شونده می­دیدند، تعدادی از خبره‌­های این صنعت که خود را اتحاد چابک[۲] نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش هایی را معرفی کردند تا تیم­های نرم افزاری سریعتر نرم افزار را توسعه داده و زودتر به تغییرات پاسخ دهند. چند ماه بعد، این گروه ارزش­هایی تعریف شده را تحت مانیفست اتحاد چابک در سایت http://agilemanifesto.org منتشر کردند.

مانیفست اتحاد چابک

ما با توسعه نرم افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعه نرم افزار هستیم. از این کار به ارزش‌های زیر می­رسیم :

۱- افراد و تعاملات بالاتر از فرآیندها و ابزارها

۲- نرم افزار کار کننده بالاتر از  مستندات جامع

۳- مشارکت مشتری بالاتر از قرارداد کاری

۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.

افراد و تعاملات بالاتر از فرآیندها و ابزارها

افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرآیند عالی بدون نیروی مناسب منجر به شکست می­گردد و بر عکس افراد قوی تحت فرآیند ضعیت ناکارآمد خواهند بود.

یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.

در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می­توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفا به آنها به عنوان امکانی جهت تسهیل فرآیندها نگاه کنید.

نرم افزار کار کننده بالاتر از  مستندات جامع

نرم افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.

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

بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.

اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می­دهیم. ما آنها را بخشی از تیم می­کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می­دهیم.

مشارکت مشتری بالاتر از قرارداد کاری

نرم افزار نمی­تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.

این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می‌کند، بسازند. اما این تعامل به کیفیت پایین نرم افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتبا اعمال نظر می­کند.

قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساسا نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.

پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است. وقتی که طرحی را می­ریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.

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

یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.

اصول چابک

۱- بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم افزار با ارزش. تحویل نرم افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه می‌رود.

۲- خوش آمدگویی به تغییرات حتی در انتهای توسعه. اعضای تیم چابک، تغییرات را چیز خوبی می‌بینند زیرا تغییرات به این معنی است که تیم بیشتر یاد گرفته است که چه چیزی مشتری را راضی می‌کند.

۳- تحویل نرم افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاهتر. ما مجموعه از مستندات و طرحها را به مشتری نمی‌دهیم.

۴- افراد مسلط به بیزنس و توسعه دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. یک پروژه نرم افزاری نیاز به هدایت مداوم دارد.

۵- ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید.  مهمترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت  فاکتورهای بعدی محسوب می­شوند که اگر تاثیر بدی روی افراد می­گذارند، باید تغییر کنند.

۶- بهترین و موثر‌ترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. در تیم چابک افراد با یکدیگر صحبت می‌کنند. نامه نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد.

۷- نرم افزار کار کننده معیار اصلی پیشرفت است. پروژه‌های چابک با نرم افزاری که در حال حاضر نیازهای مشتری را پاسخ می‌دهد، سنجیده می‌شوند. میزان مستندات، حجم کدهای زیر ساخت و هر چیز دیگری غیره از نرم افزار کار کننده معیار پیشرفت نرم افزار نیستند.

۸- فرآیندهای چابک توسعه با آهنگ ثابت را ترویج می‌دهد. حامیان، توسعه دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند که بیشتر شبیه به دو  ماراتون است یا دوی ۱۰۰ متر. آنها با سرعتی کار می‌کنند که بالاترین کیفیت را ارائه دهند.

۹- توجه مداوم به برتری تکنیکی و طراحی خوب منجر به چابکی می­گردد. کیفیت بالاتر کلیدی برای سرعت بالا است. راه سریعتر رفتن این است که نرم افزار تا جایی که ممکن است پاک و قوی نگهداریم. بنابراین همه اعضای تیم چابک تلاش می­کنند که با کیفیت­ترین کار ممکن را انجام دهند. آنها هر آشفتگی را به محض ایجاد برطرف می‌کنند.

۱۰-  سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. تیم چابک همیشه ساده‌ترین مسیر که با هدف آنها سازگار است را در پیش می­گیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمی­گذارند.  آنها کار امروز را با کیفیت انجام داده و مطمئن می­شوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود.

۱۱-  بهترین معماری و طراحی از تیم‌های خود سازمان ده بیرون می‌آید. مدیران، مسئولیت‌ها را به یک فردی  خاصی در تیم نمی‌دهند بلکه بر عکس با تیم به صورت یک نیروی واحد برخورد می­کنند. خود تیم تصمیم می­گیرد که هر مسئولیت را چه کسی انجام دهد. تیم چابک با هم روی کل جنبه‌های پروژه کار می­کنند. یعنی یک فرد خاص مسئول معماری، برنامه نویسی، تست و غیره نیستند. تیم، مسئولیتها را به اشتراک گذاشته و هر فرد بر کل کار تاثیر دارد.

۱۲-  در بازهای زمانی مناسب تیم در می­یابد که چگونه می­تواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد. تیم می­داند که محیط دائما در حال تغییر است، بنابراین خود را با محیط تغییر می­دهد تا چابک بماند.

ضرورت توسعه چابک

امروزه صنعت نرم افزار دارای سابقه بدی در تحویل به موقع و با کیفیت نرم افزار است. گزارشات بسیاری تایید می­کنند که بیش از ۸۰ درصد از پروژه‌های نرم افزاری با شکست مواجه می­شوند؛ در سال ۲۰۰۵ موسسه IEEE  برآورد زده است که بیش از ۶۰ بیلیون دلار صرف پروژه‌های نرم افزاری شکست خورده شده است. عجب فاجعه­ای؟

شش دلیل اصلی شکست پروژه‌های نرم افزاری

وقتی که از مدیران و کارکنان سوال می­شود که چرا پروژه‌های نرم افزاری با شکست مواجه می­شوند، آنها به موضوعات گسترده ای اشاره می­کنند. اما شش دلیل زیر بارها و بارها تکرار شده است که به عنوان دلایل اصلی شکست نرم افزار معرفی می­شوند:

۱- درگیر نشدن  مشتری

۲- عدم درک درست نیازمندها

۳- زمان بندی غیر واقعی

۴- عدم پذیریش و مدیریت تغییرات

۵- کمبود تست نرم افزار

۶- فرآیندهای غیر منعطف و باد دار

چگونه چابکی این مشکلات را رفع می­کند؟

با آنکه Agile برای هر مشکلی راه حل ندارد ولی برای مسائل فوق بدین صورت کمک می­کند:

مشتری پادشاه است!

برای رفع مشکل عدم همکاری کاربر نهایی یا مشتری، Agile مشتری را عضوی از تیم توسعه می­کند. به عنوان عضوی از تیم، مشتری با تیم توسعه کار می­کند تا مطمئن شود که نیازمندها به درستی برآورده می­شوند. مشتری همکاری می­کند در شناسایی نیازمندی­ها، تایید می­کند نتیجه نهایی را و حرف آخر را در اینکه کدام ویژگی به نرم افزار اضافه شود، حذف شود و یا تغییر کند، را می­زند.

نیازمندی‌ها به صورت تست­های پذیرش[۳] نوشته می­شوند

برای مقابله با مشکل عدم درک درست نیازمندی­ها، Agile تاکید دارد که نیازمندیهای کسب شده باید به صورت ویژگی­هایی تعریف شوند که بر اساس معیارهای مشخصی قابل پذیرش باشند. این معیارهای پذیرش برای نوشتن تست­های پذیرش به کار می­روند. به این ترتیب قبل از اینکه کدی نوشته شود، ابتدا تست پذیرش نوشته می­شود. این بدین معنی است که هر کسی باید اول فکر کند که چه می­خواهد، قبل از اینکه از کسی بخواهد آن را انجام دهد. این راهکار فرایند کسب نیازمندی­ها را از بنیاد تغییر می­دهد و به صورت چشم گیری کیفیت برآورد و زمان بندی را بهبود می­دهد.

زمانبندی با مذاکره بین تیم توسعه و سفارش دهنده تنظیم می­شود

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

هیچ چیزی روی سنگ حک نشده است، مگر تاریخ تحویل

برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile  می­گوید که هر چیزی می­تواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت می­کند، مشتری (در تیم محصول) می­تواند بر اساس اولویت­ها و ارزش­های خود ویژگی­های محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت می­گردد.

تست­ها قبل از کد نوشته می­شوند و کاملا خودکار هستند

برای رفع مشکل کمبود تست، Agile تاکید می­کند که ابتدا باید تست­ها نوشته شوند و همواره ارزیابی گردند. هر برنامه نویس باید اول تست­ را بنویسد، سپس کد لازم برای پاس شدن آن را. همین که کد تغییر می­کند باید تست­ها دوباره اجرا شوند. در این راهکار، هر برنامه نویس مسئول تست­های خود است تا درستی برنامه از ابتدا تضمین گردد.

مدیریت پروژه یک فعالیت جداگانه نیست

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

به کار گیری توسعه چابک

یکی از مشکلات توسعه چابک این است که شما اول باید به خوبی آن را درک کنید تا قادر به پیاده سازی درست آن باشید. این درک هم باید کلی باشد (مانند Scrum و XP) و هم جزئی (مانند TDD و جلسات روازنه). اما چگونه باید به این درک برسیم؟ کتاب­ها و مقالات انگلیسی زیادی برای یادگیری توسعه چابک و پیاده سازی آن در سازمان وجود دارند، ولی متاسفانه منابع فارسی کمی در این زمینه است. هدف این کتاب رفع این کمبود و آموزش عملی توسعه چابک و ابزارهای پیاده سازی آن است.

برای این یک توسعه دهنده چابک شوید، باید به مهارت­های فردی و تیمی چابک برسید. در ادامه این مهارت­ها معرفی می­شوند.

مهارت­های فردی

قبل از هر چیز شما باید یک برنامه نویس باشید و مقدمات برنامه نویسی مانند الگوریتم و فلوچارت، دستورات برنامه نویسی، کار با متغیرها، توابع و آرایه­‌ها را بلد باشید. پس از تسلط به مقدمات برنامه نویسی می­توانید مهارت­های برنامه نویسی چابک را فرا بگیرید که عبارتند از:

- برنامه نویسی شیءگرا

- توسعه تست محور

- الگوهای طراحی

در ادامه نحوه کسب این مهارت­ها بیان می­شوند.

برنامه نویسی شیءگرا

اساس طراحی چابک بر تفکر شیءگرا استوار است. بنابراین تسلط به مفاهیم و طراحی شیءگرا ضروری است. 

توسعه تست محور

مهمترین و انقلابی‌ترین سبک برنامه نویسی از دهه گذشته تا به امروز، توسعه یا برنامه نویسی تست محور است. این سبک بسیاری از ارزش‌های توسعه چابک را فراهم می­کند و یادگیری آن برای هر توسعه دهنده چابک ضروری است.

الگوهای طراحی

الگوهای طراحی راه حل­های انتزاعی سطح بالا هستند. این الگوها بهترین تکنیک­های[۴] طراحی نرم افزار هستند و بسیاری از مشکلاتی که در طراحی نرم افزار رخ می­دهند با استفاده از این الگوها قابل حل هستند.

مهارت­های تیمی

انجام پروژه نرم افزاری یک کار تیمی است. شما پس از یادگیری مهارت­های فردی باید خود را آماده حضور در تیم توسعه چابک کنید. برای این منظور باید با مهارت تیمی مانند آشنایی با گردشکار تولید نرم افزار، حضور موثر در جلسات، قبول مسئولیت­ها و غیره آشنا شوید.

اسکرام

تمامی مهارت­های تیمی توسعه چابک توسط اسکرام آموزش داده می­شوند. اسکرام فریم ورکی برای توسعه چابک است که با تعریف فرآیندها، نقش­ها و آرتیفکت­های مشخص به تیم­های نرم افزاری کمک می­کند تا چابک شوند.

[۱] Artifact : خروجی یک فرآیند  است. مثلا خروجی طراحی شیءگرا، نمودارهای UML است.

[۲] Agile Alliance

[3] Acceptance Tests

[4] Best Practice

--------------------------------

اطلاعات بیشتر در http://AgileDevelopment.ir

‫۱۰ سال و ۱۱ ماه قبل، دوشنبه ۱۱ آذر ۱۳۹۲، ساعت ۱۵:۵۵
وحید نصیری وحید نصیری
مطالب
مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت اول - معرفی
مستندسازی یک API، مهم است. اگر این API عمومی باشد، نیاز به مستندات ویژه‌ی آن، امری بدیهی است و اگر عمومی نباشد، باز هم باید دارای مستندات باشد؛ از این جهت که سایر توسعه دهنده‌های یک تیم بتوانند به سادگی از آن استفاده کنند و همچنین نیازی نباشد تا یک سؤال مشخص را بارها پاسخ داد. به علاوه عدم وجود مستندات کافی در مورد یک API سبب خواهد شد تا سایر توسعه دهنده‌ها تصور کنند قابلیتی که مدنظرشان است هنوز پیاده سازی نشده‌است و خودشان شروع به توسعه‌ی آن کنند که سبب اتلاف وقت و هزینه خواهد شد. با استفاده از Swagger که «سوواَگِر» تلفظ می‌شود و یا OpenAI می‌توان این مشکل را برطرف کرد که ارائه دهنده‌ی توضیحی استاندارد از API شما می‌باشد. توسط آن می‌توان قابلیت‌های یک API را دریافت و یا نحوه‌ی تعامل با آن‌را از طریق HTTP، بررسی کرد. چون خروجی آن استاندارد است و مبتنی بر JSON و یا YAML می‌باشد، ابزارهایی نیز برای آن تهیه شده‌اند که برای نمونه می‌توانند بر مبنای آن، یک UI را طراحی و ارائه کنند. البته این ابزارهای ثالث صرفا محدود به تولید UI مستندات مبتنی بر OpenAPI نیستند، بلکه امکان تولید کد و یا آزمون‌های واحد نیز توسط آن‌ها وجود دارد.
به OpenAPI Specification عبارت Swagger Specification نیز گفته می‌شود؛ اما OpenAPI عبارتی است که باید ترجیح داده شود.


OpenAPI و Swagger

تا اینجا دریافتیم که استاندارد OpenAPI و یا Swagger، صرفا دو واژه برای انجام کاری مشابه هستند. اما در عمل Swagger تشکیل شده‌است از تعدادی ابزار سورس باز که برفراز استاندارد OpenAPI کار کرده و قابلیت‌هایی را ارائه می‌دهند؛ مانند Swagger Editor (برای تولید استاندارد)، Swagger UI (برای تولید UI مستندات)، Swagger CodeGen (برای تولید کدهای خودکار) و غیره. برای نمونه swagger-ui را می‌توانید در مخزن کد GitHub آن ملاحظه کنید.
البته این ابزارها به صورت عمومی تهیه شده‌اند. به همین جهت محصور کننده‌هایی نیز برای آن‌ها جهت یکپارچگی با ASP.NET Core، طراحی شده‌اند؛ مانند میان‌افزار Swashbuckle.AspNetCore. کار آن تولید OpenAPI Specification بر اساس ASP.NET Core 2x API شما می‌باشد که جزئیات انجام اینکار را به مرور بررسی خواهیم کرد. این کامپوننت به همراه یک swagger-ui جایگذاری شده (embedded) نیز می‌باشد که کار تهیه‌ی یک UI خودکار را بر اساس این استاندارد میسر می‌کند.
البته محصورکننده‌های متعددی برای ابزارهای Swagger، برای پروژه‌های ASP.NET Core وجود دارند که یکی دیگر از آن‌ها NSwag است. هرچند Swashbuckle.AspNetCore پرکاربردترین مورد تا به امروز بوده‌است.


ساختار نمونه برنامه‌ای که در این سری تکمیل خواهد شد


در اینجا ساختار برنامه‌ی ASP.NET Core 2.2x نمونه‌ی این سری را ملاحظه می‌کنید که هدف اصلی آن، ارائه‌ی دو کنترلر Web API برای کتاب‌ها و نویسنده‌های آن‌ها می‌باشد:


برای نمونه اگر برنامه را اجرا کنید، در مسیر https://localhost:5001/api/authors، لیست تمام نویسندگانی که به صورت اطلاعات آغازین برنامه، توسط OpenAPISwaggerDoc.DataLayer ثبت شده‌اند، قابل مشاهده‌است:


و یا کتاب‌های نویسنده‌ای خاص را در آدرسی مانند https://localhost:5001/api/authors/2902b665-1190-4c70-9915-b9c2d7680450/books می‌توان مشاهده کرد:



کدهای کامل آغازین این نمونه برنامه را از اینجا می‌توانید دریافت کنید: OpenAPISwaggerDoc-01.zip و شامل این اجزا است:
- OpenAPISwaggerDoc.Entities: به همراه موجودیت‌های نویسنده و کتاب است.
- OpenAPISwaggerDoc.DataLayer: شامل DbContext برنامه است؛ به همراه تعدادی رکورد پیش‌فرض جهت آغاز بانک اطلاعاتی و چون DbContext را در یک پروژه‌ی مجزا قرار داده‌ایم، نیاز به IDesignTimeDbContextFactory نیز دارد که این مورد هم در این پروژه لحاظ شده‌است.
- OpenAPISwaggerDoc.Models: شامل DTOهای برنامه است. برای نگاشت این DTOها به موجودیت‌ها و برعکس، از AutoMapper استفاده شده‌است که کار این نگاشت‌ها و تعریف پروفایل متناظر با آن‌ها، در پروژه‌ی OpenAPISwaggerDoc.Profiles صورت می‌گیرد.
- OpenAPISwaggerDoc.Services: کار استفاده‌ی از لایه‌ی OpenAPISwaggerDoc.DataLayer را جهت دسترسی به بانک اطلاعاتی و کار با موجودیت‌های کتاب‌ها و نویسندگان، انجام می‌دهد. از این سرویس‌ها در دو کنترلر Web API برنامه، برای دریافت اطلاعات نویسندگان و کتاب‌های آن‌ها از بانک اطلاعاتی، استفاده می‌شود.
- OpenAPISwaggerDoc.Web: پروژه‌ی اصلی است که دو کنترلر Web API را هاست می‌کند و تنظیمات اولیه‌ی این سرویس‌ها را در کلاس Startup انجام داده و همچنین کار اعمال خودکار Migrations را نیز در کلاس Program (بالاترین سطح برنامه) تکمیل می‌کند. رشته‌ی اتصالی این برنامه، در فایل appsettings.json تعریف شده‌است و به یک بانک اطلاعاتی LocalDB اشاره می‌کند که پس از اجرای برنامه به صورت خودکار ساخته شده و مقدار دهی می‌شود.


در قسمت بعد، کار مستند سازی این API را شروع می‌کنیم.
‫۵ سال و ۶ ماه قبل، سه‌شنبه ۲۷ فروردین ۱۳۹۸، ساعت ۱۹:۳۰
وحید نصیری وحید نصیری
مطالب
بررسی تغییرات Blazor 8x - قسمت دوم - بررسی حالت رندر سمت سرور
در قسمت قبل، حالت‌های مختلف رندر کامپوننت‌ها را در Blazor 8x معرفی کردیم. در این قسمت می‌خواهیم نحوه‌ی کارکرد دو حالت InteractiveServer و StreamRendering را به همراه چند مثال بررسی کنیم.


معرفی قالب‌های جدید شروع پروژه‌های Blazor در دات نت 8

پس از نصب SDK دات نت 8، دیگر خبری از قالب‌های قدیمی پروژه‌های blazor server و blazor wasm نیست! در اینجا در ابتدا باید مشخص کرد که سطح تعاملی برنامه در چه حدی است. در ادامه 4 روش شروع پروژه‌های Blazor 8x را مشاهده می‌کنید که توسط پرچم interactivity--، نوع رندر برنامه در آن‌ها مشخص شده‌است:

اجرای قسمت‌های تعاملی برنامه بر روی سرور:
dotnet new blazor --interactivity Server

اجرای قسمت‌های تعاملی برنامه در مرورگر، توسط فناوری وب‌اسمبلی:
dotnet new blazor --interactivity WebAssembly

برای اجرای قسمت‌های تعاملی برنامه، ابتدا حالت Server فعالسازی می‌شود تا فایل‌های WebAssembly دریافت شوند، سپس فقط از WebAssembly استفاده می‌کند:
dotnet new blazor --interactivity Auto

فقط از حالت SSR یا همان static server rendering استفاده می‌شود (این نوع برنامه‌ها تعاملی نیستند):
dotnet new blazor --interactivity None

سایر گزینه‌ها را با اجرای دستور dotnet new blazor --help می‌توانید مشاهده کنید.


نکته‌ی مهم! در قالب‌های آماده‌ی Blazor 8x، حالت SSR، پیش‌فرض است.

هرچند در تمام پروژه‌های فوق، انتخاب حالت‌های مختلف رندر را مشاهده می‌کنید، اما این انتخاب‌ها صرفا دو مقصود مهم را دنبال می‌کنند:
الف) تنظیم فایل Program.cs برنامه جهت افزودن وابستگی‌های مورد نیاز، به صورت خودکار.
ب) ایجاد پروژه‌ی کلاینت (علاوه بر پروژه‌ی سرور)، در صورت نیاز. برای مثال حالت‌های وب‌اسمبلی و Auto، هر دو به همراه یک پروژه‌ی کلاینت وب‌اسمبلی هم هستند؛ اما حالت‌های Server و None، خیر.

در تمام این پروژه‌ها هر صفحه و یا کامپوننتی که ایجاد می‌شود، به صورت پیش‌فرض بر اساس SSR رندر و نمایش داده خواهد شد؛ مگر اینکه به صورت صریحی این نحوه‌ی رندر را بازنویسی کنیم. برای مثال مشخص کنیم که قرار است بر اساس Blazor Server اجرا شود و یا وب‌اسمبلی و یا حالت Auto.

اما ... اگر علاقمند بودیم تا به حالت‌های پیش‌از دات نت 8 رجوع کنیم و تمام برنامه را به صورت یک‌دست تعاملی کنیم و حالت SSR پیش‌فرض نباشد، می‌توان از پرچم all-interactive-- که به انتهای دستورات فوق قابل افزوده شدن است، کمک گرفت. این پرچم، فایل App.Razor را جهت تنظیم سراسری حالت‌های رندر، ویرایش می‌کند. این مورد را در ادامه‌ی این مطلب، در قسمت «روشی ساده برای تعاملی کردن کل برنامه» بیشتر بررسی می‌کنیم.


بررسی حالت Server side rendering

برای بررسی این حالت یک پوشه‌ی جدید را ایجاد کرده و توسط خط فرمان، دستور dotnet new blazor --interactivity Server را در ریشه‌ی آن اجرا می‌کنیم. پس از ایجاد ساختار ابتدایی پروژه بر اساس این قالب انتخابی، فایل Program.cs جدید آن، چنین شکلی را دارد:
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorComponents().AddInteractiveServerComponents();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}

app.UseHttpsRedirection();

app.UseStaticFiles();
app.UseAntiforgery();

app.MapRazorComponents<App>().AddInteractiveServerRenderMode();

app.Run();
مهم‌ترین قسمت‌های آن، متدهای AddInteractiveServerComponents و AddInteractiveServerRenderMode هستند که server-side rendering را به همراه امکان داشتن کامپوننت‌های تعاملی، میسر می‌کنند.
server-side rendering به این معنا است که برنامه‌ی سمت سرور، کل DOM و HTML نهایی را تولید کرده و به مرورگر کاربر ارائه می‌کند. مرورگر هم این DOM را نمایش می‌دهد. فقط همین! در اینجا هیچ خبری از اتصال دائم SignalR نیست و محتوای ارائه شده، یک محتوای استاتیک است. این حالت رندر، برای ارائه‌ی محتواهای فقط خواندنی غیرتعاملی، فوق العاده‌است؛ امکان از لحظه‌ای که نیاز به کلیک بر روی دکمه‌ای باشد، دیگر پاسخگو نیست. به همین جهت در اینجا امکان تعاملی کردن تعدادی از کامپوننت‌های ویژه و مدنظر نیز پیش‌بینی شده‌اند تا بتوان به ترکیبی از server-side rendering و client-side rendering رسید.
حالت پیش‌فرض در اینجا، ارائه‌ی محتوای استاتیک است. بنابراین هر کامپوننتی در اینجا ابتدا بر روی سرور رندر شده (HTML ابتدایی آن آماده شده) و به سمت مرورگر کاربر ارسال می‌شود. اگر کامپوننتی نیاز به امکانات تعاملی داشت باید آن‌را دقیقا توسط ویژگی InteractiveXYZ مشخص کند؛ مانند مثال زیر:
@page "/counter"
@rendermode InteractiveServer

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}
همانطور که مشاهده می‌کنید، این کامپوننت از روش رندر InteractiveServer استفاده می‌کند. برای درک نحوه‌ی کارکرد آن، همین سطر را حذف، یا کامنت کنید و سپس برنامه را اجرا کنید. در حین مشاهده‌ی این صفحه، همه چیز به خوبی نمایش داده می‌شود و حتی دکمه‌ی Click me هم مشخص است. اما ... با کلیک بر روی آن اتفاقی رخ نمی‌دهد! علت اینجا است که اکنون این صفحه، یک صفحه‌ی کاملا استاتیک است و دیگر تعاملی نیست.
در ادامه، مجددا سطر کامنت شده را به حالت عادی برگردانید و سپس برنامه را اجرا کنید. پیش از باز کردن صفحه‌ی Counter، ابتدا developer tools مرورگر خود را گشوده و برگه‌ی network آن‌را انتخاب و سپس صفحه‌ی Counter را باز کنید. در این لحظه‌است که مشاهده می‌کنید یک اتصال وب‌سوکت برقرار شد. این اتصال است که قابلیت‌های تعاملی صفحه را برقرار کرده و مدیریت می‌کند (این اتصال دائم SignalR است که این صفحه را همانند برنامه‌های Blazor Web Server پیشین مدیریت می‌کند).

یک نکته: در برنامه‌های Blazor Server سنتی، امکان فعالسازی قابلیتی به نام prerender نیز وجود دارد. یعنی سرور، ابتدا صفحه را رندر کرده و محتوای استاتیک آن‌را به سمت مرورگر کاربر ارسال می‌کند و سپس اتصال SignalR برقرار می‌شود. در دات نت 8، این حالت، حالت پیش‌فرض است. اگر آن‌را نمی‌خواهید باید به نحو زیر غیرفعالش کنید:
@rendermode InteractiveServerRenderModeWithoutPrerendering

@code{
  static readonly IComponentRenderMode InteractiveServerRenderModeWithoutPrerendering = 
        new InteractiveServerRenderMode(false);
}


روشی ساده برای تعاملی کردن کل برنامه

اگر می‌خواهید رفتار برنامه را همانند Blazor Server سابق کنید و نمی‌خواهید به ازای هر کامپوننت، نحوه‌ی رندر آن‌را به صورت سفارشی انتخاب کنید، فقط کافی است فایل App.razor را باز کرده:
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <base href="/" />
    <link rel="stylesheet" href="bootstrap/bootstrap.min.css" />
    <link rel="stylesheet" href="app.css" />
    <link rel="stylesheet" href="MyApp.styles.css" />
    <link rel="icon" type="image/png" href="favicon.png" />
    <HeadOutlet />
</head>

<body>
    <Routes />
    <script src="_framework/blazor.web.js"></script>
</body>

</html>
و قسمت‌های HeadOutlet و مسیریابی آن‌را به صورت زیر تغییر دهید تا به کل برنامه اعمال شود:
<HeadOutlet @rendermode="@InteractiveServer" />
...
<Routes @rendermode="@InteractiveServer" />
این مورد دقیقا همان کاری است که پرچم all-interactive-- در هنگام ایجاد پروژه‌های جدید Blazor 8x به کمک NET CLI.، انجام می‌دهد. یک چنین گزینه‌ای در ویژوال استودیو نیز هنگام ایجاد پروژه‌ها‌ی جدید Blazor وجود دارد و به شما این امکان را می‌دهد که بین حالت‌های تعاملی Per page/component و Global، یکی را انتخاب کنید. در حین استفاده‌ی از CLI، نیازی به ذکر حالت تعاملی Per page/component نیست؛ چون حالت پیش‌فرض، یا همان SSR است. حالت Global هم فقط فایل App.Razor را به صورت فوق، ویرایش و تنظیم می‌کند.


در این حالت دیگر نیازی نیست تا به ازای هر کامپوننت و صفحه، نحوه‌ی رندر را مشخص کنیم؛ چون این نحوه، از بالاترین سطح، به تمام زیرکامپوننت‌ها به ارث می‌رسد (درباره‌ی این نکته در قسمت قبل، توضیحاتی ارائه شد).


بررسی حالت Streaming Rendering

در اینجا مثال پیش‌فرض Weather.razor قالب پیش‌فرض مورد استفاده‌ی جاری را کمی تغییر داده‌ایم که کدهای نهایی آن به صورت زیر است (2 قسمت forecasts.AddRange_ را اضافه‌تر دارد):

@page "/weather"
@attribute [StreamRendering(prerender: true)]

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (_forecasts == null)
{
    <p>
        <em>Loading...</em>
    </p>
}
else
{
    <table class="table">
        <thead>
        <tr>
            <th>Date</th>
            <th>Temp. (C)</th>
            <th>Temp. (F)</th>
            <th>Summary</th>
        </tr>
        </thead>
        <tbody>
        @foreach (var forecast in _forecasts)
        {
            <tr>
                <td>@forecast.Date.ToShortDateString()</td>
                <td>@forecast.TemperatureC</td>
                <td>@forecast.TemperatureF</td>
                <td>@forecast.Summary</td>
            </tr>
        }
        </tbody>
    </table>
}

@code {
    private List<WeatherForecast>? _forecasts;

    protected override async Task OnInitializedAsync()
    {
    // Simulate asynchronous loading to demonstrate streaming rendering
        await Task.Delay(500);

        var startDate = DateOnly.FromDateTime(DateTime.Now);
        var summaries = new[]
                        {
                            "Freezing",
                            "Bracing",
                            "Chilly",
                            "Cool",
                            "Mild",
                            "Warm",
                            "Balmy",
                            "Hot",
                            "Sweltering",
                            "Scorching",
                        };
        _forecasts = GetWeatherForecasts(startDate, summaries).ToList();
        StateHasChanged();

    // Simulate asynchronous loading to demonstrate streaming rendering
        await Task.Delay(1000);
        _forecasts.AddRange(GetWeatherForecasts(startDate, summaries));
        StateHasChanged();

        await Task.Delay(1000);
        _forecasts.AddRange(GetWeatherForecasts(startDate, summaries));
    }

    private static IEnumerable<WeatherForecast> GetWeatherForecasts(DateOnly startDate, string[] summaries)
    {
        return Enumerable.Range(1, 5)
                         .Select(index => new WeatherForecast
                                          {
                                              Date = startDate.AddDays(index),
                                              TemperatureC = Random.Shared.Next(-20, 55),
                                              Summary = summaries[Random.Shared.Next(summaries.Length)],
                                          });
    }

    private class WeatherForecast
    {
        public DateOnly Date { get; set; }
        public int TemperatureC { get; set; }
        public string? Summary { get; set; }
        public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    }

}
برای بررسی این مثال، ابتدا سطر ویژگی StreamRendering را حذف و یا کامنت کرده و سپس برنامه را اجرا کنید. پس از اجرای برنامه، با انتخاب مشاهده‌ی صفحه‌ی Weather، هیچگاه قسمت loading که در حالت forecasts == null_ قرار است ظاهر شود، نمایش داده نمی‌شود؛ چون در این حالت (حذف نوع رندر)، صفحه‌ی نهایی که به کاربر ارائه خواهد شد، یک صفحه‌ی استاتیک کاملا رندر شده‌ی در سمت سرور است و کاربر باید تا زمان پایان این رندر در سمت سرور، منتظر بماند و سپس صفحه‌ی نهایی را دریافت و مشاهده کند. در این حالت امکانات تعاملی Blazor server وجود خارجی ندارند.
در ادامه مجددا سطر ویژگی StreamRendering را به حالت قبلی برگردانید و برنامه را اجرا کنید. در این حالت ابتدا قسمت loading ظاهر می‌شود و سپس در طی چند مرحله با توجه به Task.Delay‌های قرار داده شده، صفحه رندر شده و تکمیل می‌شود.
اتفاقی که در اینجا رخ می‌دهد، استفاده از فناوری  HTML Streaming است که مختص به مایکروسافت هم نیست. در حالت Streaming، هربار قطعه‌ای از HTML ای که قرار است به کاربر ارائه شود، به صورت جریانی به سمت مرورگر ارسال می‌شود و مرورگر این قطعه‌ی جدید را بلافاصله نمایش می‌دهد. نکته‌ی جالب این روش، عدم نیاز به اتصال SignalR و یا اجرای WASM درون مرورگر است.

Streaming rendering حالت بینابین رندر کامل در سمت سرور و رندر کامل در سمت کلاینت است. در حالت رندر سمت سرور، کل HTML صفحه ابتدا توسط سرور تهیه و بازگشت داده می‌شود و کاربر باید تا پایان عملیات تهیه‌ی این HTML نهایی، منتظر باقی بماند و در این بین چیزی را مشاهده نخواهد کرد. در حالت Streaming rendering، هنوز هم همان حالت تهیه‌ی HTML استاتیک سمت سرور برقرار است؛ به همراه تعدادی محل جایگذاری اطلاعات جدید. به محض پایان یک عمل async سمت سرور که سه نمونه‌ی آن را در مثال فوق مشاهده می‌کنید، برنامه، جریان قطعه‌ای از اطلاعات استاتیک را به سمت مرورگر کاربر ارسال می‌کند تا در مکان‌هایی از پیش تعیین شده، درج شوند.
در حالت SSR، فقط یکبار شانس ارسال کل اطلاعات به سمت مرورگر کاربر وجود دارد؛ اما در حالت Streaming rendering، ابتدا می‌توان یک قالب HTML ای را بازگشت داد و سپس مابقی محتوای آن‌را به محض آماده شدن در طی چند مرحله بازگشت داد. در این حالت نمایش گزارشی از اطلاعاتی که ممکن است با تاخیر در سمت سرور تهیه شوند، ساده‌تر می‌شود. یعنی می‌توان هربار قسمتی را که تهیه شده، برای نمایش بازگشت داد و کاربر تا مدت زیادی منتظر نمایش کل صفحه باقی نخواهد ماند.


روش نهایی معرفی نحوه‌ی رندر صفحات

بجای استفاده از ویژگی‌های RenderModeXyz جهت معرفی نحوه‌ی رندر کامپوننت‌ها و صفحات (که تا پیش از نگارش RTM معرفی شده بودند و چندبار هم تغییر کردند)، می‌توان از دایرکتیو جدیدی به نام rendermode@ با سه مقدار InteractiveServer، InteractiveWebAssembly و InteractiveAuto استفاده کرد. برای سهولت تعریف این موارد باید سطر ذیل را به فایل Imports.razor_ اضافه نمود:
@using static Microsoft.AspNetCore.Components.Web.RenderMode
در این حالت تعریف قدیمی سطر ذیل:
@attribute [RenderModeInteractiveServer]
به صورت زیر:
@rendermode InteractiveServer
تبدیل می‌شود.

اگر هم قصد سفارشی سازی آن‌ها را دارید، برای مثال می‌خواهید prerender را در آن‌ها false کنید، روش کار به صورت زیر است:
@rendermode renderMode

@code {
    static IComponentRenderMode renderMode = new InteractiveWebAssemblyRenderMode(prerender: false);
}
‫۱۱ ماه قبل، چهارشنبه ۲۴ آبان ۱۴۰۲، ساعت ۰۱:۴۵
وحید نصیری وحید نصیری
مطالب
آشنایی با Refactoring - قسمت 2

قسمت دوم آشنایی با Refactoring به معرفی روش «استخراج متدها» اختصاص دارد. این نوع Refactoring بسیار ساده بوده و مزایای بسیاری را به همراه دارد؛ منجمله:
- بالا بردن خوانایی کد؛ از این جهت که منطق طولانی یک متد به متدهای کوچکتری با نام‌های مفهوم شکسته می‌شود.
- به این ترتیب نیاز به مستند سازی کدها نیز بسیار کاهش خواهد یافت. بنابراین در یک متد، هر جایی که نیاز به نوشتن کامنت وجود داشت، یعنی باید همینجا آن‌ قسمت را جدا کرده و در متد دیگری که نام آن، همان خلاصه کامنت مورد نظر است، قرار داد.
- این نوع جدا سازی منطق‌های پیاده سازی قسمت‌های مختلف یک متد، در آینده نگهداری کد نهایی را نیز ساده‌تر کرده و انجام تغییرات بر روی آن را نیز تسهیل می‌بخشد؛ زیرا اینبار بجای هراس از دستکاری یک متد طولانی، با چند متد کوچک و مشخص سروکار داریم.

برای نمونه به مثال زیر دقت کنید:
using System.Collections.Generic;

namespace Refactoring.Day2.ExtractMethod.Before
{
    public class Receipt
    {
        private IList<decimal> Discounts { get; set; }
        private IList<decimal> ItemTotals { get; set; }

        public decimal CalculateGrandTotal()
        {
            // Calculate SubTotal
            decimal subTotal = 0m;
            foreach (decimal itemTotal in ItemTotals)
                subTotal += itemTotal;

            // Calculate Discounts
            if (Discounts.Count > 0)
            {
                foreach (decimal discount in Discounts)
                    subTotal -= discount;
            }

            // Calculate Tax
            decimal tax = subTotal * 0.065m;
            subTotal += tax;

            return subTotal;
        }
    }
}

همانطور که از کامنت‌های داخل متد CalculateGrandTotal مشخص است، این متد سه کار مختلف را انجام می‌دهد؛ جمع اعداد، اعمال تخفیف، اعمال مالیات و نهایتا یک نتیجه را باز می‌گرداند. بنابراین بهتر است هر عمل را به یک متد جداگانه و مشخص منتقل کرده و کامنت‌های ذکر شده را نیز حذف کنیم. نام یک متد باید به اندازه‌ی کافی مشخص و مفهوم باشد و آنچنان نیازی به مستندات خاصی نداشته باشد:

using System.Collections.Generic;

namespace Refactoring.Day2.ExtractMethod.After
{
    public class Receipt
    {
        private IList<decimal> Discounts { get; set; }
        private IList<decimal> ItemTotals { get; set; }

        public decimal CalculateGrandTotal()
        {
            decimal subTotal = CalculateSubTotal();
            subTotal = CalculateDiscounts(subTotal);
            subTotal = CalculateTax(subTotal);
            return subTotal;
        }

        private decimal CalculateTax(decimal subTotal)
        {
            decimal tax = subTotal * 0.065m;
            subTotal += tax;
            return subTotal;
        }

        private decimal CalculateDiscounts(decimal subTotal)
        {
            if (Discounts.Count > 0)
            {
                foreach (decimal discount in Discounts)
                    subTotal -= discount;
            }
            return subTotal;
        }

        private decimal CalculateSubTotal()
        {
            decimal subTotal = 0m;
            foreach (decimal itemTotal in ItemTotals)
                subTotal += itemTotal;
            return subTotal;
        }
    }
}

بهتر شد! عملکرد کد نهایی، تغییری نکرده اما کیفیت کد ما بهبود یافته است (همان مفهوم و معنای Refactoring). خوانایی کد افزایش یافته است. نیاز به کامنت نویسی به شدت کاهش پیدا کرده و از همه مهم‌تر، اعمال مختلف، در متدهای خاص آن‌ها قرار گرفته‌اند.
به همین جهت اگر حین کد نویسی، به یک متد طولانی برخوردید (این مورد بسیار شایع است)، در ابتدا حداقل کاری را که جهت بهبود کیفیت آن می‌توانید انجام دهید، «استخراج متدها» است.

ابزارهای کمکی جهت پیاده سازی روش «استخراج متدها»:

- ابزار Refactoring توکار ویژوال استودیو پس از انتخاب یک قطعه کد و سپس کلیک راست و انتخاب گزینه‌ی Refactor->Extract method، این عملیات را به خوبی می‌تواند مدیریت کند و در وقت شما صرفه جویی خواهد کرد.
- افزونه‌های ReSharper و همچنین CodeRush نیز چنین قابلیتی را ارائه می‌دهند؛ البته توانمندی‌های آن‌ها از ابزار توکار یاد شده بیشتر است. برای مثال اگر در میانه کد شما جایی return وجود داشته باشد، گزینه‌ی Extract method ویژوال استودیو کار نخواهد کرد. اما سایر ابزارهای یاده شده به خوبی از پس این موارد و سایر موارد پیشرفته‌تر بر می‌آیند.

نتیجه گیری:
نوشتن کامنت، داخل بدنه‌ی یک متد مزموم است؛ حداقل به دو دلیل:
- ابزارهای خودکار مستند سازی از روی کامنت‌های نوشته شده، از این نوع کامنت‌ها صرفنظر خواهند کرد و در کتابخانه‌ی شما مدفون خواهند شد (یک کار بی‌حاصل).
- وجود کامنت در داخل بدنه‌ی یک متد، نمود آشکار ضعف شما در کپسوله سازی منطق مرتبط با آن قسمت است.


و ... «لطفا» این نوع پیاده سازی‌ها را خارج از فایل code behind هر نوع برنامه‌ی winform/wpf/asp.net و غیره قرار دهید. تا حد امکان سعی کنید این مکان‌ها، استفاده کننده‌ی «نهایی» منطق‌های پیاده سازی شده توسط کلاس‌های دیگر باشند؛ نه اینکه خودشان محل اصلی قرارگیری و ابتدای تعریف منطق‌های مورد نیاز قسمت‌های مختلف همان فرم مورد نظر باشند. «لطفا» یک فرم درست نکنید با 3000 سطر کد که در قسمت code behind آن قرار گرفته‌اند. code behind را محل «نهایی» ارائه کار قرار دهید؛ نه نقطه‌ی آغاز تعریف منطق‌های پیاده سازی کار. این برنامه نویسی چندلایه که از آن صحبت می‌شود، فقط مرتبط با کار با بانک‌های اطلاعاتی نیست. در همین مثال، کدهای فرم برنامه، باید نقطه‌ی نهایی نمایش عملیات محاسبه مالیات باشند؛ نه اینکه همانجا دوستانه یک قسمت مالیات حساب شود، یک قسمت تخفیف، یک قسمت جمع بزند، همانجا هم نمایش بدهد! بعد از یک هفته می‌بینید که code behind فرم در حال انفجار است! شده 3000 سطر! بعد هم سؤال می‌پرسید که چرا اینقدر میل به «بازنویسی» سیستم این اطراف زیاد است! برنامه نویس حاضر است کل کار را از صفر بنویسد، بجای اینکه با این شاهکار بخواهد سرو کله بزند! هر چند یکی از روش‌های برخورد با این نوع کدها جهت کاهش هراس نگهداری آن‌ها، شروع به Refactoring است.

‫۱۳ سال و ۱ ماه قبل، چهارشنبه ۱۳ مهر ۱۳۹۰، ساعت ۰۳:۳۵
وحید نصیری وحید نصیری
مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 3 - Middleware چیست؟
پیشنیازها
- «با HttpHandler بیشتر آشنا شوید»
یکی از بزرگترین تغییرات ASP.NET Core نسبت به نگارش‌های قبلی آن، مدیریت HTTP pipeline آن است. به عنوان یک توسعه دهنده‌ی ASP.NET به طور قطع با مفاهیمی مانند HttpHandler و HttpModules آشنایی دارید و ... هر دوی این‌ها با نگارش جدید ASP.NET حذف و با مفهوم جدیدی به نام Middleware جایگزین شده‌اند.
 - HttpHandlerها عموما مبتنی بر پسوندهای فایل‌ها عمل می‌کنند. برای نمونه، رایج‌ترین آن‌ها ASP.NET page handler است که هرگاه درخواستی، ختم شده‌ی به پسوند aspx، به موتور ASP.NET Web forms وارد شد، به این page handler، جهت پردازش نهایی هدایت می‌شود. محل تنظیم آن‌ها نیز در فایل web.config است.
 - HttpModuleها مبتنی بر رخدادها عمل می‌کنند. HttpModuleها به عنوان جزئی از request pipeline عمل کرده و دسترسی کاملی دارند به رخدادهای طول عمر درخواست رسیده. آن‌ها را می‌توان توسط فایل‌های global.asax و یا web.config تنظیم کرد.
 - MiddleWareها را که جزئی از طراحی OWIN نیز هستند، می‌توان به عنوان کامپوننت‌های کوچکی از برنامه که قابلیت یکپارچه شدن با HTTP request pipeline را دارند، درنظر گرفت. عملکرد آن‌ها ترکیبی است از هر دوی HttpHandler و HttpModule‌ها که در نگارش‌های قبلی ASP.NET مورد استفاده بودند. از MiddleWareها می‌توان برای پیاده سازی اعمال مختلفی جهت پردازش درخواست‌های رسیده مانند اعتبارسنجی، کار با سشن‌ها، ثبت وقایع سیستم، مسیریابی و غیره استفاده کرد. OWIN یا Open Web Interface for .NET به توسعه دهنده‌ها امکان غیروابسته کردن برنامه‌ی ASP.NET خود را از وب سرور مورد استفاده می‌دهد. به علاوه OWIN امکان پلاگین نویسی اجزای مختلف برنامه را بدون وابسته کردن آن‌ها به یکدیگر فراهم می‌کند. برای مثال می‌توان یک پلاگین logger را تهیه کرد تا اطلاعات مختلفی را از درخواست‌های رسیده ثبت کند.



مواردی که با ارائه‌ی ASP.NET Core 1.0 حذف شده‌اند

- System.Web: یکی از اهداف اصلی OWIN، مستقل کردن برنامه‌ی وب، از هاست آن است تا بتوان از وب سرورهای بیشتری استفاده کرد. System.Web انحصارا برای IIS طراحی شده بود و در این نگارش دیگر وجود خارجی ندارد.
- HttpModules: با Middlewareها جایگزین شده‌اند.
- HttpHandlers: البته HttpHandlers از زمان ارائه‌ی اولین نگارش ASP.NET MVC، در چندین سال قبل منسوخ شدند. زیرا پردازش صفحات وب در ASP.NET MVC برخلاف وب فرم‌ها، از فایل‌هایی با پسوندهای خاص شروع نمی‌شوند و نقطه‌ی آغازین آن‌ها، اکشن متدهای کنترلرها است.
- فایل global.asax: با حذف شدن HttpModules، دیگر ضرورتی به وجود این فایل نیست.


شباهت‌های بینMiddleware و HttpModuleها

همانند HttpModuleها، Middlewareها نیز به ازای هر درخواست رسیده اجرا می‌شوند و از هر دو می‌توان جهت تولید response ایی خاص استفاده کرد.


تفاوت‌های بینMiddleware و HttpModuleها

- عموما HttpModule از طریق web.config و یا فایل global.asax تنظیم می‌شوند. اما Middlewareها تنها از طریق کد و در فایل Startup.cs برنامه‌های ASP.NET Core 1.0 قابل معرفی هستند.
- به عنوان یک توسعه دهنده، کنترلی را بر روی ترتیب اجرای انواع و اقسام HttpModuleها نداریم. این مشکل در Middlewareها برطرف شده و اکنون ترتیب اجرای آن‌ها، دقیقا مطابق ترتیب افزوده شدن و تعریف آن‌ها در فایل Startup.cs است.
- ترتیب اجرای HttpModuleها هرچه که باشد، برای حالت‌های request و response یکی است. اما ترتیب اجرای Middlewareهای مخصوص response، عکس ترتیب اجرای Middlewareهای مخصوص request هستند (تصویر ذیل).
- HttpModuleها را صرفا جهت اتصال کدهایی به رخدادهای طول عمر برنامه می‌توان طراحی کرد؛ اما Middleware مستقل هستند از این رخدادها.
- HttpModuleها به System.Web وابسته‌اند؛ برخلاف Middlewareها که وابستگی به هاست خود ندارند.



Middleware‌های توکار ASP.NET Core 1.0

ASP.NET Core 1.0 به همراه تعدادی Middleware توکار است؛ مانند:
- Authentication: جهت پشتیبانی از اعتبارسنجی
- CORS: برای فعال سازی Cross-Origin Resource Sharing
- Routing: جهت تعریف و محدود سازی مسیریابی‌های برنامه
- Session: برای پشتیبانی و مدیریت سشن‌های کاربران
- Diagnostics: پشتیبانی از صفحات خطا و اطلاعات زمان اجرای برنامه
و مواردی دیگر که برای توزیع فایل‌های استاتیک و یا مرور محتویات پوشه‌ها و امثال آن‌ها طراحی شده‌اند که در طی این مطلب و همچنین مطالب آتی، آن‌ها را بررسی خواهیم کرد.

یک مثال: اگر یک پروژه‌ی خالی ASP.NET Core 1.0 را در ویژوال استودیو ایجاد کنید، این پروژه قادر نیست حتی فایل‌های استاتیک مانند تصاویر، فایل‌های پیش فرض مانند index.html و یا قابلیت مرور ساده‌ی فایل‌های موجود در یک پوشه را ارائه دهد (حتی اگر به آن‌ها نیازی نداشته باشید).
طراحی این نگارش از ASP.NET، مبتنی است بر سبک وزن بودن و ماژولار بودن. هر قابلیتی را که نیاز دارید، باید middleware آن‌را نیز خودتان به صورت صریح اضافه کنید و یا در غیر اینصورت فعال نیست. برخلاف نگارش‌های قبلی ASP.NET که HTTP Module‌های از سشن گرفته تا اعتبارسنجی و غیره، همگی به صورت پیش فرض در فایل Web.Config فعال بودند؛ مگر اینکه آن‌ها را به صورت دستی حذف می‌کردید.



ثبت و فعال سازی اولین Middleware

در ادامه‌ی تکمیل و معرفی برنامه‌ی خالی ASP.NET Core 1.0، قصد داریم یک Middleware توکار را به نام Welcome Page، بجای نمایش سطر Hello world پیش فرض این برنامه، ثبت و فعال سازی کنیم. این Middleware ویژه، در اسمبلی به نام Microsoft.AspNetCore.Diagnostics قرار دارد. اگر فایل project.json پیش فرض این پروژه را باز کنید، این اسمبلی به صورت پیش فرض در آن ثبت و معرفی شده‌است:
{
    "dependencies": {
        "Microsoft.NETCore.App": {
            "version": "1.0.0",
            "type": "platform"
        },
        "Microsoft.AspNetCore.Diagnostics": "1.0.0",
        "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
        "Microsoft.Extensions.Logging.Console": "1.0.0"
    },
بنابراین هم اکنون بسته‌ی نیوگت آن نیز به پروژه‌ی جاری اضافه شده و قابل استفاده است. در غیراینصورت همانطور که در قسمت قبل در مطلب «نقش فایل project.json» عنوان شد، می‌توان بر روی گره references کلیک راست کرده و سپس از منوی ظاهر شده،‌گزینه‌ی manage nuget packages را انتخاب کرد. سپس، ابتدا برگه‌ی browse را انتخاب کنید و در اینجا نام Microsoft.AspNetCore.Diagnostics را جستجو کرده و در آخر آن‌را نصب کنید.
پس از اطمینان حاصل کردن از نصب بسته‌ی نیوگت Microsoft.AspNetCore.Diagnostics، اکنون جهت معرفی Middleware توکار Welcome Page ، فایل Startup.cs را گشوده و کدهای آن‌را به نحو ذیل تغییر  دهید:
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
 
namespace Core1RtmEmptyTest
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
        }
 
        public void Configure(IApplicationBuilder app)
        {
            app.UseWelcomePage();
 
            app.Run(async (context) =>
            {
                await context.Response.WriteAsync("Hello DNT!");
            });
        }
    }
}
در اینجا نحوه‌ی ثبت این middleware را با افزودن آن به IApplicationBuilder تزریق شده‌ی توسط OWIN، به کمک متد الحاقی UseWelcomePage مشاهده می‌کنید.
به علاوه middleware دومی را نیز با متد الحاقی Run مشاهده می‌کنید. به این نوع middlewareهای خاص، اصطلاحا terminal middleware می‌گویند. از این جهت که درخواستی را دریافت و یک response را تولید می‌کنند و کار همینجا خاتمه می‌یابد و زنجیره‌ی پردازشی middlewareها ادامه نخواهد یافت. در اینجا پارامتر context آن از نوع HttpContext است و باید دقت داشت، زمانیکه کار نوشتن در Response، در اینجا انجام شد، اگر پس از متد Run یک Middleware دیگر را ثبت کنید، هیچگاه اجرا نخواهد شد.

در این حالت اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:


welcome page نیز یک terminal middleware است. به همین جهت middleware بعدی ثبت شده‌ی در اینجا یا همان متد Run، دیگر اجرا نخواهد شد.

در قسمت‌های بعدی، تعداد بیشتری از Middlewareهای توکار ASP.NET Core 1.0 را بررسی خواهیم کرد.
‫۸ سال و ۳ ماه قبل، پنجشنبه ۱۷ تیر ۱۳۹۵، ساعت ۱۸:۱۰
وحید نصیری وحید نصیری
مطالب
شیوه‌نامه‌های مقدماتی بوت استرپ 4
وقتی صفحه‌ی وبی را باز می‌کنید، تنظیمات بسیاری بر روی ظاهر آن تاثیرگذار هستند. برای مثال خود مرورگر دارای تنظیماتی است که بر روی ظاهر پیش‌فرض عناوین و عناصر مختلف قرار گرفته شده‌ی بر روی صفحه تاثیر گذار است. به این موارد Browser Styles گفته می‌شود که با Custom Styles ما قابلیت بازنویسی را دارند. در این بین، شیوه‌نامه‌های بوت استرپ، بین Browser Styles و شیوه‌نامه‌های سفارشی ما قرار می‌گیرند تا ظاهر بهتری را برای عناصر مختلف صفحه ارائه دهند.


تایپوگرافی مقدماتی بوت استرپ 4

شیوه‌نامه‌های همراه با بوت استرپ، رفتار و تنظیمات پیش‌فرض مرورگر را بازنویسی می‌کنند. این بازنویسی با فایل node_modules\bootstrap\scss\_reboot.scss شروع می‌شود. اگر مجموعه‌ی بوت استرپ را توسط روش معرفی شده‌ی در مطلب «روش‌های مختلف دریافت و نصب بوت استرپ 4» دریافت کرده باشید، کدهای کامل SASS آن، در پوشه‌ی scss این مجموعه، موجود هستند که یکی از آن‌ها فایل reboot است. کار آن نرمال سازی شیوه‌نامه‌ها، به نحوی است که در مرورگرها مختلف و همچنین وسایل نمایشی متفاوت، یکسان به نظر برسند:
 - برای مثال در این فایل از روش اندازه گیری rem استفاده شده‌است تا مدیریت اندازه‌های آن در سکوهای کاری مختلف قابل کنترل شود.
 - در اینجا از margin-top به طور کامل صرفنظر شده‌است، تا بتوان اندازه‌گیری فواصل بین عناصر را بهتر محاسبه کرد. بوت استرپ 4 تنها یک margin را در پایین تمام عناصر صفحه، تنظیم می‌کند. بنابراین آگاهی از وجود این پیش‌فرض، تنظیم فواصل بین عناصر را نیز ساده‌تر می‌کند.
 - در این فایل در همه‌جا از خاصیت inherit استفاده شده‌است تا امکان بازنویسی شیوه‌نامه‌های آن توسط custom styles ما ساده‌تر شود.
 - پیش‌فرض دیگری که در این نگارش از بوت استرپ تنظیم شده‌است، border-box می‌باشد. به این ترتیب اندازه گیری عرض عناصر ساده‌تر می‌شوند. برای مثال اگر عرض یک div را مساوی 200px قرار دهید، یک padding پیش‌فرض نیز برای آن درنظر گرفته شده‌است و padding سفارشی تنظیم شده‌ی برای آن بی‌اثر خواهد بود.
 - در این نگارش، فونت پیش‌فرض صفحه، به فونت پیش‌فرض سیستم تنظیم شده‌است و نه فونت از پیش تعیین شده‌ی خاصی. از این جهت که این قلم‌های سیستمی، دارای ویژگی‌های خاصی هستند که آن‌ها را برای سکوهای کاری مختلف، منحصربفرد می‌کنند.

مثال: نمایش تاثیر بوت استرپ 4 بر روی تایپوگرافی پیش‌فرض مرورگر 
<body>
    <div class="container">
        <section class="content" id="mission">
            <h1>Our Commitment <small>to you</small></h1>
            <p>Wisdom Pet Medicine strives to blend the best in traditional and
                <em>alternative medicine</em> in the <strong>diagnosis and
                    treatment</strong> of companion animals including dogs,
                cats, birds, reptiles, rodents, and fish. We apply the wisdom
                garnered in the <mark>centuries old tradition</mark> of
                veterinary medicine, to find the safest treatments
                and&nbsp;cures.</p>
            <p>We strive to be your pet's medical <del>staff</del> experts from
                youth through the senior years. <small>We build preventative
                    health care plans for each and every one of our patients,
                    based on breed, age, and sex, so that your pet receives the
                    most appropriate care at crucial milestones.</small> We
                want to give your pet a long and healthy&nbsp;life.</p>
        </section>

        <section class="content" id="services">
            <h2>Exotic Pets</h2>
            <p>We offer <strong>specialized</strong> care for <em>reptiles,
                    rodents, birds,</em> and other exotic pets.</p>

            <h3>Grooming</h3>
            <p>Our therapeutic <span>grooming</span> treatments help battle
                fleas, allergic dermatitis, and other challenging skin
                conditions.</p>

            <h4>General Health</h4>
            <p>Wellness and senior exams, ultrasound, x-ray, and dental
                cleanings are just a few of our general health services.</p>

            <h5>Nutrition</h5>
            <p>Let our nutrition experts review your pet's diet and prescribe a
                custom nutrition plan for optimum health and disease
                prevention.</p>

            <h6>Pest Control</h6>
            <p>We offer the latest advances in safe and effective prevention
                and treatment of fleas, ticks, worms, heart worm, and other
                parasites.</p>

            <h2>Vaccinations</h2>
            <p>Our veterinarians are experienced in modern vaccination
                protocols that prevent many of the deadliest diseases in pets.</p>
        </section>
    </div>
</body>
با این خروجی:

با اعمال بوت استرپ


بدون اعمال بوت استرپ


در اینجا دو تصویر راملاحظه می‌کنید؛ یکی با اعمال bootstrap.min.css به صفحه‌است و دیگری با حذف آن از صفحه. به این ترتیب مشاهده می‌کنید که صرفا اعمال بوت استرپ به یک صفحه‌ی متداول، کیفیت نمایش آن‌را با بازنویسی شیوه‌نامه‌ی پیش‌فرض مرورگر، به نحو قابل ملاحظه‌ای بهبود بخشیده‌است و آن‌را زیباتر کرده‌است.
در اینجا تنها المان بوت استرپی که به صفحه اضافه شده‌است و جزو استانداردهای HTML نیست، یک div با کلاس container است:
<body>
    <div class="container">
کل محتوای صفحه جهت اعمال شیوه‌نامه‌های بوت استرپ، داخل این div قرار می‌گیرند. اولین تاثیر آن واکنشگرا کردن صفحه‌است و همچنین یک padding را نیز به قسمت‌های چپ و راست صفحه اضافه کرده‌است.
در این مثال تاثیر بوت استرپ را بر روی شیوه‌نامه‌های پیش‌فرض خصوصا  h1 تا h6، مشاهده می‌کنید.
روش دیگر تعریف headings در اینجا، استفاده از کلاس‌هایی با نام‌های مشابه است:
<div class="h1">Test div class H1</div>
علاوه بر آن، کلاس display نیز در اینجا برای تعیین اندازه‌ی headings سفارشی پیش بینی شده‌است که می‌توان از عدد 1 تا 4 را توسط آن تنظیم کرد:
<div class="display-1">Test div class display-1</div>
با این خروجی و اندازه در مقایسه با headings استاندارد که امکان تعریف تیترهایی بزرگ‌تر از اندازه‌های متداول را میسر می‌کنند:


همچنین اگر نیاز به بزرگتر نمایش دادن متن قسمت ابتدایی صفحه وجود داشت، می‌توان از کلاس Lead استفاده کرد:
<p class="lead">Testing a lead class</p>



کلاس‌های کمکی کار با متون در بوت استرپ 4

بوت استرپ 4 به همراه تعدادی کلاس کمکی کار با متون است که نیازهای متداول تایپوگرافی را برآورده می‌کنند:

1) کلاس‌های کمکی محل قرارگیری متون
- کلاس text-justify کار کشیدن و متناسب کردن یک پاراگراف را با گوشه‌های سمت چپ و راست صفحه انجام می‌دهد.
- کلاس text-nowrap از شکسته شدن متن به چندین سطر جلوگیری می‌کند. برای مثال می‌تواند برای نمایش کدها مناسب باشد.
- کلاس متغیر text-xx-pos برای تعیین محل قرارگیری متن کاربرد دارد:
در اینجا ذکر xx اختیاری است و می‌تواند sm، برای اندازه‌های صفحه‌ی بیشتر از 576px و یا md، برای اندازه‌های صفحه‌ی بیشتر از 768px و یا lg، برای اندازه‌های صفحه‌ی بیشتر از 992px و یا xl، برای اندازه‌های صفحه‌ی بیشتر از 1200px باشد. این اندازه‌های یاد شده را در ادامه بیشتر مشاهده خواهید کرد.
همچنین pos می‌تواند left ،center و یا right باشد.
برای مثال کلاس text-sm-center به این معنا است که متن مدنظر در break-point ایی به نام sm، یعنی با اندازه‌ی صفحه‌ی بیشتر از 576px، در وسط صفحه نمایش داده خواهد شد.

2) کلاس‌های نمایش upper-case و lower-case حروف
- کلاس text-lowercase کار نمایش lower-case کل یک پاراگراف اعمالی را انجام می‌دهد.
- کلاس text-uppercase کار نمایش upper-case کل یک پاراگراف اعمالی را انجام می‌دهد.
- کلاس text-capitalize، اولین حرف هر واژه را به صورت بزرگ نمایش می‌دهد.

3) کلاس‌های شیوه‌ی نمایش متون
کلاس font-weight-bold، کلاس font-weight-normal و کلاس font-italic نمایش ضخیم، عادی و یا italic متن را سبب می‌شوند.

مثال: بررسی تاثیر کلاس‌های کمکی کار با متون در بوت استرپ 4 
<body>
    <div class="container">
        <section class="content" id="mission">
            <h1 class="text-center text-sm-right text-md-left text-uppercase">Our
                Commitment</h1>
            <p class="lead text-justify">Wisdom Pet Medicine strives to blend
                the best in
                traditional and <em>alternative medicine</em> in the <strong>diagnosis
                    and treatment</strong> of companion animals including dogs,
                cats, birds, reptiles, rodents, and fish. We apply the wisdom
                garnered in the <mark>centuries old tradition</mark> of
                veterinary medicine, to find the safest treatments
                and&nbsp;cures.</p>
            <p class="text-nowrap text-capitalize">We strive to be your pet's
                medical <del>staff</del>
                experts from
                youth through the senior years. <small>We build preventative
                    health care plans for each and every one of our patients,
                    based on breed, age, and sex, so that your pet receives the
                    most appropriate care at crucial milestones.</small> We
                want to give your pet a long and healthy&nbsp;life.</p>
        </section>

        <section class="content" id="services">
            <div class="display-4">Exotic Pets</div>
            <p>We <span class="font-weight-bold">offer</span> <strong class="font-weight-normal">specialized</strong>
                care for <em>reptiles,
                    rodents, birds,</em> and other exotic pets.</p>

            <h3 class="text-left text-md-center text-sm-right">Grooming</h3>
            <p>Our therapeutic <span>grooming</span> treatments help battle
                fleas, allergic dermatitis, and other challenging skin
                conditions.</p>

            <h4>General Health</h4>
            <p>Wellness and senior exams, ultrasound, x-ray, and dental
                cleanings are just a few of our general health services.</p>

            <h5>Nutrition</h5>
            <p>Let our nutrition experts review your pet's diet and prescribe a
                custom nutrition plan for optimum health and disease
                prevention.</p>

            <h6>Pest Control</h6>
            <p>We offer the latest advances in safe and effective prevention
                and treatment of fleas, ticks, worms, heart worm, and other
                parasites.</p>

            <h2>Vaccinations</h2>
            <p>Our veterinarians are experienced in modern vaccination
                protocols that prevent many of the deadliest diseases in pets.</p>
        </section>
    </div>
</body>
با این خروجی


در اینجا اگر کلاس text-right را به heading اضافه کنیم:
<h1 class="text-right">Our Commitment <small>to you</small></h1>
چنین خروجی حاصل می‌شود:


و یا می‌توان این کلاس‌ها را با هم ترکیب کرد:
<h1 class="text-center text-sm-right">Our Commitment <small>to you</small></h1>
این ترکیب به این معنا است:
- متن h1 در حالت عادی در وسط صفحه نمایش داده شود.


- اما متن مدنظر در break-point ایی به نام sm، یعنی با اندازه‌ی صفحه‌ی بیشتر از 576px، در سمت راست صفحه نمایش داده خواهد شد.


این اعداد توسط افزونه‌ی ViewPort نمایش داده شده‌اند.


همچنین تاثیر text-justify را نیز به اولین پاراگراف
<p class="lead text-justify">
به صورت ذیل مشاهده می‌کنید که در مقایسه با تصویر قبلی، سبب کشیده شدن متن و تنظیم آن با سمت راست و چپ صفحه شده‌است:


و یا اگر text-nowrap را به پاراگرافی اعمال کنیم:
<p class="text-nowrap">


سبب نمایش یک سطری آن خواهد شد که در اینجا با پدید آمدن یک اسکرول بار افقی، قابل ملاحظه‌است.


کلاس‌های کمکی کار با لیست‌ها و نقل قول‌ها در بوت استرپ 4

بوت استرپ 4 به همراه کلاس‌هایی کمکی برای کار با لیست‌ها و نقل قول‌ها است؛ مانند:
- کلاس list-unstyled سبب حذف bullets از یک لیست می‌شود.
- برای ایجاد لیست‌های Inline می‌توان از کلاس list-inline بر روی المان UL و سپس list-inline-item بر روی هر LI آن، کمک گرفت.
<body>
    <div class="container">
        <section class="content" id="services">
            <h2>Exotic Pets</h2>
            <p>We offer <strong>specialized</strong> care for <em>reptiles,
                    rodents, birds,</em> and other exotic pets.</p>
            <ul class="list-unstyled">
                <li>Grooming</li>
                <li>General Health</li>
                <li>Nutrition</li>
                <li>Pest Control</li>
                <li>Vaccinations</li>
            </ul>

            <ul class="list-inline">
                <li class="list-inline-item">Grooming</li>
                <li class="list-inline-item">General Health</li>
                <li class="list-inline-item">Nutrition</li>
                <li class="list-inline-item">Pest Control</li>
                <li class="list-inline-item">Vaccinations</li>
            </ul>
        </section>
    </div>
</body>
در این مثال نحوه‌ی حذف bullets و همچنین inline تعریف کردن دو لیست را مشاهده می‌کنید؛ با این خروجی:


در حالت لیست inline، آیتم‌های لیست از چپ به راست در یک سطر نمایش داده می‌شوند. برای مثال می‌تواند برای نمایش breadcrumbs در یک سایت مناسب باشد.
همچنین برای نمایش نقل قول‌ها می‌توان از کلاس blockquote و برای نمایش بهتر امضای آن از کلاس blockquote-footer استفاده کرد:
<body>
    <div class="container">
        <section class="content" id="testimonials">
            <h2>Testimonials</h2>

            <blockquote>
                During the summer, our rabbit, Tonto, began to have severe
                redness and itching on his belly and feet. I'm very thankful to
                the veterinarians and staff at Wisdom for the excellent care
                Tonto received, and for nipping his allergies in the bud, so to
                speak.
                Jane
            </blockquote>

            <blockquote class="blockquote text-right">
                When Samantha, our Siamese cat, began sleeping all the time and
                urinating excessively, we brought her to see the specialists at
                Wisdom. Now, two years later, Samantha is still free from any
                complications of diabetes, and her blood sugar regularly tests
                normal.
                <div class="blockquote-footer">
                    The McPhersons
                </div>
            </blockquote>
        </section>
    </div>
</body>


در اینجا دو blockquote را مشاهده می‌کنید. مورد اول بدون کلاس blockquote است و دومی به همراه این کلاس و یک footer تعریف شده‌است. همچنین می‌توان کلاس‌هایی مانند text-right را نیز به blockquote اضافه کرد.
البته در نگارش 4، حاشیه‌ی خاکستری blockquote که در نگارش سوم آن وجود داشت، حذف شده‌است.


کار با رنگ‌ها در بوت استرپ 4

بوت استرپ، به همراه تعدادی کلاس مخصوص رنگ‌ها است که از آن در همه جا استفاده می‌کند؛ مانند رنگ‌های دکمه‌ها، پس زمینه‌ها و متون.
1) کلاس‌های تعیین رنگ متون:


برای مثال در اینجا بجای Color می‌توان یکی از ثوابت ذیل آن‌را قید کرد؛ مانند text-primary و یا text-danger
این کلاس‌ها برای تعیین رنگ متون و همچنین لینک‌ها کاربرد دارند.


2) کلاس‌های تعیین رنگ پس زمینه:


در اینجا برای نمونه بجای Color می‌توان یکی از ثوابت ذیل آن‌را قید کرد؛ مانند bg-primary و یا bg-danger

مثال: اعمال رنگ‌های زمینه‌ای بوت استرپ 
<body>
    <div class="container">
        <section class="content" id="services">
            <h2 class="text-danger">Our Mission</h2>
            <p class="bg-danger text-white">Wisdom Pet Medicine strives to
                blend the best in
                traditional and
                alternative medicine in the diagnosis and treatment of
                companion animals including dogs, cats, birds, reptiles,
                rodents, and fish. We apply the wisdom garnered in the
                centuries old tradition of veterinary medicine, to find the
                safest treatments and cures.</p>

            <ul>
                <li><a class="text-warning" href="#">Grooming</a></li>
                <li><a href="#">General Health</a></li>
                <li><a href="#">Nutrition</a></li>
                <li><a href="#">Pest Control</a></li>
                <li><a href="#">Vaccinations</a></li>
            </ul>

        </section>

        <section class="content" id="testimonials">
            <h2>Testimonials</h2>

            <blockquote class="blockquote bg-faded text-info">
                During the summer, our rabbit, Tonto, began to have severe
                redness and itching on his belly and feet. I'm very thankful to
                the veterinarians and staff at Wisdom for the excellent care
                Tonto received, and for nipping his allergies in the bud, so to
                speak.
                <div class="blockquote-footer">
                    Jane
                </div>
            </blockquote>
        </section>
    </div>
</body>
با این خروجی


در اینجا مثال‌هایی را از اعمال کلاس‌های رنگ‌های بوت استرپ مشاهده می‌کنید. همچنین امکان ترکیب آن‌ها مانند مثال زیر نیز وجود دارد:
<p class="bg-danger text-white">



کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: Bootstrap4_02.zip
‫۶ سال قبل، یکشنبه ۱۵ مهر ۱۳۹۷، ساعت ۱۷:۵۰
وحید نصیری وحید نصیری
مطالب
ASP.NET MVC #15

فیلترها در ASP.NET MVC

پایه قسمت‌های بعدی مانند مباحث امنیت، اعتبار سنجی کاربران، caching و غیره، مبحثی است به نام فیلترها در ASP.NET MVC. تابحال با سه فیلتر به نام‌های ActionName، NonAction و AcceptVerbs آشنا شده‌ایم. به این‌ها Action selector filters هم گفته می‌شود. زمانیکه قرار است یک درخواست رسیده به متدی در یک کنترلر خاص نگاشت شود،‌ فریم ورک ابتدا به متادیتای اعمالی به متدها توجه کرده و بر این اساس درخواست را به متدی صحیح هدایت خواهد کرد. ActionName، نام پیش فرض یک متد را بازنویسی می‌کند و توسط AcceptVerbs اجرای یک متد، به افعالی مانند POST، GET، DELETE و امثال آن محدود می‌شود که در قسمت‌های قبل در مورد آن‌ها بحث شد.
علاوه بر این‌ها یک سری فیلتر دیگر نیز در ASP.NET MVC وجود دارند که آن‌ها نیز به شکل متادیتا به متدهای کنترلرها اعمال شده و کار نهایی‌اشان تزریق کدهایی است که باید پیش و پس از اجرای یک اکشن متد،‌ اجرا شوند. 4 نوع فیلتر در ASP.NET MVC وجود دارند:
الف) IAuthorizationFilter
این نوع فیلترها پیش از اجرای هر متد یا فیلتر دیگری در کنترلر جاری اجرا شده و امکان لغو اجرای آن‌را فراهم می‌کنند. پیاده سازی پیش‌فرض آن توسط کلاس AuthorizeAttribute در فریم ورک وجود دارد.
بدیهی است این نوع اعمال را مستقیما داخل متدهای کنترلرها نیز می‌توان انجام داد (بدون نیاز به هیچگونه فیلتری). اما به این ترتیب حجم کدهای تکراری در سراسر برنامه به شدت افزایش می‌یابد و نگهداری آن‌را در طول زمان مشکل خواهد ساخت.

ب) IActionFilter
ActionFilterها پیش (OnActionExecuting) و پس از (OnActionExecuted) اجرای متدهای کنترلر جاری اجرا می‌شوند و همچنین پیش از ارائه خروجی نهایی متدها. به این ترتیب برای مثال می‌توان نحوه رندر یک View را تحت کنترل گرفت. این اینترفیس توسط کلاس ActionFilterAttribute در فریم ورک پیاده سازی شده است.

ج) IResultFilter
ResultFilter بسیار شبیه به ActionFilter است با این تفاوت که تنها پیش از (OnResultExecuting) بازگرداندن نتیجه متد و همچنین پس از (OnResultExecuted) اجرای متد، فراخوانی می‌گردد. کلاس ActionFilterAttribute موجود در فریم ورک، پیاده سازی پیش فرضی از آن‌‌را ارائه می‌دهد.

د) IExceptionFilter
ExceptionFilterها پس از اجرای تمامی فیلترهای دیگر، همواره اجرا خواهند شد؛ صرفنظر از اینکه آیا در این بین استثنایی رخ داده است یا خیر. بنابراین یکی از کاربردهای آن‌ها می‌تواند ثبت وقایع مرتبط با استثناهای رخ‌داده باشد. پیاده سازی پیش فرض آن توسط کلاس HandleErrorAttribute در فریم ورک موجود است.

علت معرفی 4 نوع فیلتر متفاوت هم به مسایل امنیتی بر می‌گردد. می‌شد تنها موارد ب و ج معرفی شوند اما از آنجائیکه نیاز است مورد الف همواره پیش از اجرای متدی و همچنین تمامی فیلترهای دیگر فراخوانی شود، احتمال بروز اشتباه در نحوه و ترتیب معرفی این فیلترها وجود داشت. به همین دلیل روش معرفی صریح مورد الف در پیش گرفته شد. برای مثال فرض کنید که اگر از روی اشتباه فیلتر کش شدن اطلاعات پیش از فیلتر اعتبار سنجی کاربر جاری اجرا می‌شد چه مشکلات امنیتی ممکن بود بروز کند.

مثالی جهت درک بهتر ترتیب و نحوه اجرای فیلترها:

یک پروژه جدید خالی ASP.NET MVC را آغاز کنید. سپس فیلتر سفارشی زیر را به برنامه اضافه نمائید:

using System.Diagnostics;
using System.Web.Mvc;

namespace MvcApplication12.CustomFilters
{
    public class LogAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            Log("OnActionExecuting", filterContext);
        }

        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            Log("OnActionExecuted", filterContext);
        }

        public override void OnResultExecuting(ResultExecutingContext filterContext)
        {
            Log("OnResultExecuting", filterContext);
        }

        public override void OnResultExecuted(ResultExecutedContext filterContext)
        {
            Log("OnResultExecuted", filterContext);
        }

        private void Log(string stage, ControllerContext ctx)
        {
            ctx.HttpContext.Response.Write(
                string.Format("{0}:{1} - {2} < br/> ",
                ctx.RouteData.Values["controller"], ctx.RouteData.Values["action"], stage));
        }
    }
}

مرسوم است برای ایجاد فیلترهای سفارشی، همانند مثال فوق با ارث بری از پیاده سازی‌های توکار اینترفیس‌های چهارگانه یاد شده، کار شروع شود.
سپس یک کنترلر جدید را به همراه دو متد، به برنامه اضافه نمائید. برای هر کدام از متدها هم یک View خالی را ایجاد کنید. اکنون این ویژگی جدید را به هر کدام از این متدها اعمال نموده و برنامه را اجرا کنید.

using System.Web.Mvc;
using MvcApplication12.CustomFilters;

namespace MvcApplication12.Controllers
{
    public class HomeController : Controller
    {
        [Log]
        public ActionResult Index()
        {
            return View();
        }

        [Log]
        public ActionResult Test()
        {
            return View();
        }
    }
}

سپس ویژگی Log را از متدها حذف کرده و به خود کنترلر اعمال کنید:
[Log]
public class HomeController : Controller

در این حالت ویژگی اعمالی، پیش از اجرای متد درخواستی جاری اجرا خواهد شد یا به عبارتی به تمام متدهای قابل دسترسی کنترلر اعمال می‌گردد.


تقدم و تاخر اجرای فیلترهای هم‌خانواده

همانطور که عنوان شد، همیشه ابتدا AuthorizationFilter اجرا می‌شود و در آخر ExceptionFilter. سؤال: اگر در این بین مثلا دو نوع ActionFilter متفاوت به یک متد اعمال شدند، کدامیک ابتدا اجرا می‌شود؟
تمام فیلترها از کلاسی به نام FilterAttribute مشتق می‌شوند که دارای خاصیتی است به نام Order. بنابراین جهت مشخص سازی ترتیب اجرای فیلترها تنها کافی است این خاصیت مقدار دهی شود. برای مثال جهت اعمال دو فیلتر سفارشی زیر:

using System.Diagnostics;
using System.Web.Mvc;

namespace MvcApplication12.CustomFilters
{
    public class AuthorizationFilterA : AuthorizeAttribute
    {
        public override void OnAuthorization(AuthorizationContext filterContext)
        {
            Debug.WriteLine("OnAuthorization : AuthorizationFilterA");
        }
    }
}

using System.Diagnostics;
using System.Web.Mvc;

namespace MvcApplication12.CustomFilters
{
    public class AuthorizationFilterB : AuthorizeAttribute
    {
        public override void OnAuthorization(AuthorizationContext filterContext)
        {
            Debug.WriteLine("OnAuthorization : AuthorizationFilterB");
        }
    }
}

خواهیم داشت:
using System.Web.Mvc;
using MvcApplication12.CustomFilters;

namespace MvcApplication12.Controllers
{
    public class HomeController : Controller
    {
        [AuthorizationFilterA(Order = 2)]
        [AuthorizationFilterB(Order = 1)]
        public ActionResult Index()
        {
            return View();
        }
    }
}

در اینجا با توجه به مقادیر order، ابتدا AuthorizationFilterB اجرا می‌گردد و سپس AuthorizationFilterA.
علاوه بر این‌ها محدوده اجرای فیلترها نیز بر بر این حق تقدم اجرایی تاثیر گذار هستند. برای مثال در پشت صحنه زمانیکه قرار است یک فیلتر جدید اجرا شود، وهله سازی آن به نحوه زیر است که بر اساس مقادیر order و FilterScope صورت می‌گیرد:
var filter = new Filter(actionFilter, FilterScope, order);

مقادیر FilterScope را در ادامه ملاحظه می‌نمائید:
namespace System.Web.Mvc { 
      public enum FilterScope {
            First = 0,
            Global = 10,
            Controller = 20,
            Action = 30,
            Last = 100,
        }
}

به صورت پیش فرض، ابتدا فیلتری با محدوده اجرای کمتر، اجرا خواهد شد. در اینجا Global به معنای اجرای شدن در تمام کنترلرها است.


تعریف فیلترهای سراسری

برای اینکه فیلتری را عمومی و سراسری تعریف کنیم، تنها کافی است آن‌را در متد Application_Start فایل Global.asax.cs به نحو زیر معرفی نمائیم:

GobalFilters.Filters.Add(new AuthorizationFilterA() { Order = 2});

به این ترتیب AuthorizationFilterA، به تمام کنترلرها و متدهای قابل دسترسی آن‌ها در برنامه به صورت خودکار اعمال خواهد شد.
یکی از کاربردهای فیلترهای سراسری، نوشتن برنامه‌های پروفایلر است. برنامه‌هایی که برای مثال مدت زمان اجرای متدها را ثبت کرده و بر این اساس بهتر می‌توان کارآیی قسمت‌های مختلف برنامه را دقیقا زیرنظر قرار داد.


یک نکته
کلاس کنترلر در ASP.NET MVC نیز یک فیلتر است:
public abstract class Controller : ControllerBase, IActionFilter, IAuthorizationFilter, IDisposable, IExceptionFilter, IResultFilter

به همین دلیل، امکان تحریف متدهای OnActionExecuting، OnActionExecuted و امثال آن که پیشتر ذکر شد، در یک کنترلر نیز وجود دارد.
کلاس کنترلر دارای محدوده اجرایی First و Order ایی مساوی Int32.MinValue است. به این ترتیب کنترلرها پیش از اجرای هر فیلتر دیگری اجرا خواهند شد.


ASP.NET MVC دارای یک سری فیلتر و متادیتای توکار مانند OutputCache، HandleError، RequireHttps، ValidateInpute و غیره است که توضیحات بیشتر آن‌ها به قسمت‌های بعد موکول می‌گردد.

‫۱۲ سال و ۷ ماه قبل، یکشنبه ۲۷ فروردین ۱۳۹۱، ساعت ۰۳:۴۹
وحید نصیری وحید نصیری
مطالب
وضعیت فناوری‌های مرتبط با دات نت از دیدگاه مرگ و زندگی!

مطلبی که در ذیل آورده شده صرفا یک برداشت شخصی است بر اساس نقل قول‌ها و بررسی وضعیت اعضای تیم‌های مرتبط با فناوری‌های مختلف بکار گرفته شده در دات نت فریم ورک و ... نه رسمی!

ADO.NET ، DataSet ، DataTable و امثال آن: مرده! (مرده به معنای اینکه دیگر توسعه‌ی جدی نخواهد یافت)
ADO.NET‌ اولین فناوری دسترسی به داده‌ها در دات نت فریم ورک بود/است. مدل طراحی آن هم بر اساس امکانات زبان‌های آن زمان (زمان شروع به کار دات نت) بود (و تا دات نت 4 هم تغییر عمده‌ای نکرده). برای مثال در زمان ارائه اولین نگارش آن خبری از Generics نبود (در دات نت 2 اضافه شد)؛ یا LINQ وجود نداشت (در دات نت سه و سه و نیم اضافه و تکمیل شد). به همین جهت طراحی آن در حال حاضر (با وجود دات نت 4) بوی ماندگی می‌دهد (مانند استفاده از دیتاست و دیتاتیبل) و با ORM های مایکروسافت جهت استفاده از امکانات Generics و LINQ جایگزین شده‌ است.
البته این مورد تنها مورد مرده‌ای است که "باید" یاد گرفت؛ مهم نیست که ORMs ارائه شده‌اند. مهم این است که زیر ساخت تمام ORM های نوشته شده برای دات نت همین ADO.NET خام است.


LINQ to SQL : مرده!
مایکروسافت با این فناوری ORM های خودش را شروع کرد اما بعد از مدتی دید که بهتر است یک نسخه‌ی عمومی‌تر با پشتیبانی از بانک‌های اطلاعاتی دیگر مانند اوراکل، MySQL و غیره را نیز ارائه دهد. همینجا بود که آن‌را خیلی ساده با Entity framework جایگزین کرد و در roadmap ارائه شده صراحتا EF به عنوان راه حل توصیه شده دسترسی به داده‌های مایکروسافت اعلام شده است (+). حالا این وسط دیگر مهم نیست شما پروژه نوشته بودید یا هر چی. دیگر منتظر تغییرات خاصی در LINQ to SQL نباشید. فقط یک سری رفع باگ و نگهداری پروژه را شاهد خواهید بود. البته در همان زمان خیلی زود تکذیب کردند که LINQ to SQL مرده اما برای نمونه آقای Damien که عضو اصلی تیم LINQ to SQL بودند، اکنون در تیم XBOX مشغول به کار هستند! (+) تو خود شرح مفصل بخوان از این مجمل!

ضمنا این رو هم در نظر داشته باشید که LINQ != LINQ to SQL ؛ به عبارتی LINQ به خودی خود فقط یک language feature است.


Windows Forms یا به اختصار WinForms : مرده!
به نظر مظلوم‌تر از این یکی در دات نت یافت نمی‌شود! همین چند وقت پیش یکی از اعضای مایکروسافت این نظر سنجی رو برگزار کرده بود که "ما چکار کنیم که شما راحت‌تر از WinForms به WPF مهاجرت کنید؟!" (+)
در قاموس WPF ، ویندوز فرمز یعنی Canvas panel ؛ به عبارتی صلب‌ترین حالت طراحی رابط کاربری و این انتقال و مهاجرت هرچند برای کسانی که عمری را روی آن گذاشته‌اند، دردناک خواهد بود اما با وجود توانایی‌های WPF چیزی را از دست نخواهند داد. سیستم Layout (طرح بندی) در WinForms و همچنین دلفی، بر اساس قراردهی اشیاء در مختصات مطلقی در صفحه است. مثلا این دکمه‌ی خاص در آن نقطه‌ی معلوم قرار می‌گیرد و همین. این روش طرح بندی یکی از چندین روش طرح بندی در WPF است که اصطلاحا Canvas نام دارد. توصیه اکید و مطلق در WPF آن است که از Canvas فقط برای طراحی اشیاء گرافیکی پیچیده استفاده کنید و نه طراحی رابط کاربر. چرا؟ چون برای مثال در Silverlight که برادر کوچکتر WPF محسوب می‌شود، رابط کاربری آن باید بتواند همانند HTML انعطاف پذیر باشد و با اندازه‌های مختلف مرورگر یا اندازه‌ی قلم‌های بزرگتر هماهنگ شده و مقاومت کند، بدون اینکه از ریخت بیفتد و این مورد را سایر سیستم‌های طرح بندی رابط کاربر (منهای Canvas یا همان سیستم طرح بندی WinForms) ارائه می‌دهند. مورد دیگری که در WPF و Silverlight بسیار حائز اهمیت است ، Content Controls می‌باشد. چقدر خوب می‌شد بتوان داخل یک کنترل، کلا یک سیستم طرح بندی را تعریف کرد و اشیاء دلخواهی را داخل آن قرار داد. مثلا ToolTip پیش فرض وجود دارد. بسیار هم خوب. بنده علاقه دارم، متن عنوان آن ضخیم باشد. کنار آن یک تصویر کوچک و در سمت چپ آن متن قرار گیرد. برای انجام اینکار در WPF لازم نیست تا شما منتظر نگارش بعدی دات نت باشید که دست اندرکاران مربوطه با افتخار در یک سند 50 صفحه‌ای توضیح دهند که چگونه می‌توان اینکار را انجام داد. یک سیستم طرح بندی را اضافه کنید. موارد ذکر شده را در آن تعریف کنید. بدون استفاده از هیچ نوع کامپوننتی یا بدون منتظر ماندن تا نگارش بعدی این محصولات، به مقصود خود رسیده‌اید.


ASP.NET Web forms : داره نفس‌های آخرش رو می‌کشه!
از زمانیکه ASP.NET MVC آمد نسخه‌ی Web forms تقریبا فراموش شد. به وبلاگ اسکات گاتری یا Haacked و سایر اعضای اصلی دات نت که مراجعه کنید در سه سال اخیر در حد تعداد انگشتان یک دست هم در مورد Web forms مطلب ننوشته‌اند. تمام تمرکز و نوآوری‌ها بر روی MVC متمرکز شده و حتی در نسخه‌ی 4 دات نت هم فقط یک سری صافکاری مختصر را در Web forms شاهد بودیم مثلا نام کنترل‌ها را خودتان هم در زمان رندر نهایی می‌توانید تعیین کنید! یا لطفا کردند و قسمتی از url routing موجود در ASP.NET MVC را به ASP.NET web forms 4 هم قرض دادند (این مورد شاید مهم‌ترین تغییر قابل ذکر در ASP.Net web forms 4 است).
البته این رو هم اضافه کنم که ASP.NET MVC‌ واقعا قابل احترام است؛ هدف از آن جدا سازی لایه‌های برنامه با الگوهای استاندارد صنعتی (و نه هر روش برنامه نویسی چند لایه من درآوردی)، ترویج کد نویسی بهتر، ترویج Unit testing ، رفع یک سری مشکلات ASP.NET Web forms (مثلا از ViewState های حجیم دیگر خبری نیست) و امثال آن است.
برای نمونه توجه شما را به مطلبی که آقای Dino Sposito در مورد ASP.NET Webforms نوشته جلب می‌کنم: (+)
به صورت خلاصه ایشان عنوان کرده زمان طراحی ASP.NET Webforms در 10 سال قبل، هدف ما انتقال ساده‌تر برنامه نویس‌های VB به محیط وب بود. به همین جهت دست به اختراع postback ، viewState ، کنترل‌های سمت سرور و غیره زدیم. (بنابراین تاکید تمام این‌ها این است که webforms فناوری دهه قبل "بود" و الان بنابر نیازهای جدید دست به طراحی مجدد زده‌ایم)

در مورد "پایان پروژه ASP.NET Ajax Control Toolkit" هم قبلا مطلب نوشته بودم و این یکی واقعا official است!


و در پایان باید متذکر شد که فلان فناوری مرده یا داره نفس‌های آخرش رو می‌کشه اصلا مهم نیست. هنوز هم هستند سازمان‌هایی که برنامه‌های نوشته شده با ASP کلاسیک (نگارش قبل از ASP.NET Web forms) خود را دارند و خیلی هم از آن راضی هستند!
این موارد رو از این جهت نوشتم که اگر می‌خواهید تازه به این جمع وارد شوید دقیقا بدانید باید روی چه مواردی بیشتر وقت بگذارید و یادگیری کدامیک صرفا اتلاف وقت خواهند بود (مثلا EF بر LINQ to SQL ارجح است و اگر امروز می‌خواهید شروع کنید با EF شروع کنید، یا دیگر کم کم با وجود WPF ، بازار کاری برای WinForms نخواهد بود).

‫۱۳ سال و ۱۰ ماه قبل، چهارشنبه ۱۵ دی ۱۳۸۹، ساعت ۰۲:۱۸
وحید نصیری وحید نصیری
مطالب
بررسی دقیق‌تر صفحات آبی ویندوز

حدود یک سال قبل کامپیوتری را که داشتم (اینتل پنتیوم 4) به یک AMD دوهسته‌ای ارتقاء دادم و هفته‌ی اول پس از ارتقاء، روزگار من سیاه شد! روزهای اول 2 بار کرش ویندوز و مشاهده صفحه آبی و روزهای بعد تا 7 بار این اتفاق تکرار می‌شد. حتی تا تعویض مادربرد جدید هم پیش رفتم ولی تاثیری نداشت. تست رم و غیره هم انجام شد، مشکلی نبود. خلاصه اینجا بود که از سر ناچاری به این فکر افتادم که آیا این پیغام‌های صفحه‌ی آبی ویندوز را می‌شود تفسیر کرد؟ مشکل دقیقا از کجاست؟ چون در این موارد به هر کسی که مراجعه کنید بر اساس تجربه قبلی یک نسخه برای شما خواهد پیچید. رمت خرابه! بایوست رو ارتقاء بده! (این مورد تاثیر داشت! ولی تعداد کرش‌ها صفر نشد) مادربردت مشکل داره و ...

تمام این‌ها بر اساس تجربیات قبلی این افراد است و ارزشمند. ولی آیا این جواب‌ها قانع کننده هستند؟ چرا باید رم را عوض کرد؟ از کجا فهمیدید مادربرد مشکل داره؟



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

در ویندوز این امکان وجود دارد که پس از هر بار کرش سیستم عامل و مشاهده صفحه آبی یک دامپ کرنل نیز به صورت خودکار حاصل شود. این فایل دامپ را می‌توان پس از راه اندازی مجدد سیستم با یک سری ابزار آنالیز کرد و علت دقیق کرش ویندوز را بدست آورد.
برای اینکه این فایل‌های دامپ تولید شوند باید مراحل زیر مطابق تصویر طی شوند:



اکنون بعد از هر کرش و صفحه آبی ویندوز یک فایل دامپ در دایرکتوری C:\WINDOWS\Minidump تشکیل می‌شود. برای آنالیز این فایلها به صورت زیر می‌شود عمل کرد:
ابتدا برنامه زیر را دانلود کنید:
Debugging Tools for Windows

پس از نصب، Debugging Tools for Windows را خواهید داشت که جهت دیباگ کردن سیستم و آنالیز فایلهای دامپ و غیره کاربرد دارد.

سپس مطالعه مقاله زیر در مورد نحوه استفاده از این ابزار بسیار مفید است:
http://support.microsoft.com/kb/315263

به صورت خلاصه :
یک فایل bat درست کنید با محتویات زیر و دقیقا به همین شکل:
c:\windbg\kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z %1


در این دستور سه مورد قابل ملاحظه است:
الف) مسیر فایل kd.exe که توسط پکیج Debugging Tools for Windows نصب می‌شود. (مطابق سیستم خودتان آنرا اصلاح کنید)
ب) مسیر c:\windows\i386 بدین معنا است که دایرکتوری i386 سی دی ویندوز را در این مسیر کپی کرده‌اید یا خواهید کرد (نیاز به یک ویندوز تر و تازه و نصب نشده خواهد بود).
ج) مسیر c:\symbols خودبخود ایجاد خواهد شد و فایلهای مربوطه از سایت مایکروسافت توسط برنامه kd.exe دانلود می‌شود (بنابراین باید دسترسی به اینترنت نیز داشت).

فرض کنید نام این فایل را test.bat گذاشته‌اید.
برای آنالیز فایل Mini102607-07.dmp در دایرکتوری مینی دامپ ویندوز (07 در اینجا یعنی هفتمین کرش روز مربوطه!) دستور زیر را در خط فرمان صادر کنید:
test.bat C:\WINDOWS\Minidump\Mini102607-07.dmp
پس از مدتی این برنامه کار آنالیز را تمام خواهد کرد و گزارشی را ارائه می‌دهد (یک فایل log متنی تشکیل خواهد شد).
نتیجه یک نمونه از این آنالیزهای سیستم من به صورت زیر بود:
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 02060008, Memory contents of the pool block
Arg4: 88b4a118, Address of the block of pool being deallocated

Debugging Details:
------------------

POOL_ADDRESS:  88b4a118

FREED_POOL_TAG:  TCPc

BUGCHECK_STR:  0xc2_7_TCPc

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8054a583 to 804f9deb

STACK_TEXT:
ba4f3874 8054a583 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x1b
ba4f38c4 b043d3ff 88b4a118 00000000 ba4f390c nt!ExFreePoolWithTag+0x2a3
ba4f38d4 b043cca3 883ae760 883ae7f4 883ae7f4 tcpip!TCPClose+0x16
ba4f390c b02f3161 8a74fe20 883ae760 b02f2a6d tcpip!TCPDispatch+0x101
WARNING: Stack unwind information not available. Following frames may be wrong.
ba4f3984 b03e2046 00000001 00000000 ba4f39d8 vsdatant+0x45161
ba4f39d8 b03e921c 00000008 ba4f3aac 00000000 ipnat!NatpRedirectQueryHandler+0x250
ba4f3a70 00000000 8837d8e8 0000000d 000005ee ipnat!NatpDirectPacket+0xd2

STACK_COMMAND:  kb

FOLLOWUP_IP:
vsdatant+45161
b02f3161 ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  vsdatant+45161

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vsdatant

IMAGE_NAME:  vsdatant.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  46e0766a

FAILURE_BUCKET_ID:  0xc2_7_TCPc_vsdatant+45161

BUCKET_ID:  0xc2_7_TCPc_vsdatant+45161

Followup: MachineOwner

به لاگ حاصل از دو دیدگاه می‌توان پرداخت: الف) اگر من برنامه نویس مربوطه باشم، با trace موجود در لاگ فایل، مشخص می‌شود که کجای کار مشکل داشته است ، ب) یا اینکه خیر. بنده توسعه دهنده درایور نیستم. حداقل اسم دقیق درایور یا پروسه مشکل‌زا را می‌توان از این لاگ بدست آورد.

خوب! تا اینجا مشخص شد که دلیل کرش، درایور vsdatant.sys است. با جستجو در اینترنت مشخص شد که این درایور مربوط به فایروال زون آلارم است! (همین عبارت بالا یا نام درایور ذکر شده را مستقیما در گوگل جستجو کنید)
پس از آن زون آلارم را با outpost firewall جایگزین کردم و تا الان کرشی حاصل نشده است (حتی یکبار از سال قبل تا به امروز). جدا زندگی من مختل شده بود. تصور کنید سیستم شما روزی 7 بار کرش کند!! و چه تصورات نامربوطی را نسبت به فروشنده سخت افزار در ذهن خود مرور کرده باشید!

خلاصه‌ی کلام:
صفحات آبی ویندوز قابل تفسیر هستند. پدید آمدن آنها الزاما بدلیل وجود سخت افزار معیوب نیست و به صرف اینکه شخصی به شما گفته "رمت خرابه!" اکتفا نکنید.

پ.ن.
لاگ فوق مربوط به یک سال قبل است و احتمالا شاید زون آلارم‌های جدید این مشکل را نداشته باشند.

‫۱۵ سال و ۱۲ ماه قبل، جمعه ۲۲ آذر ۱۳۸۷، ساعت ۰۳:۴۱