علی یگانه مقدم علی یگانه مقدم
مطالب
توزیع کلاس‌های اندرویدی با استفاده از Gradle قسمت اول
یکی از روش‌هایی که امروزه مورد استقبال برنامه نویسان اندروید و جاوا قرار گرفته‌است، استفاده از یک سیستم DSL به نام Gradle (+) است. ابتدا در سیستم‌های Apache Ant (+) و Maven (+) مورد استفاده قرار می‌گرفت، ولی با جمع کردن نقاط ضعف آن دو سیستم، و رفع عیوب آن‌ها و افزودن مزیت‌های جدید، Gradle ایجاد شد. یکی از استفاده‌هایی که به شدت مورد استفاده‌ی برنامه نویسان اندروید قرار می‌گیرد، استفاده از یک سیستم توزیع برای کلاس‌های اندرویدی است. اگر امروزه به خیلی از سورس‌های قرار گرفته بر روی گیت هاب، نگاه کنید، به غیر از روش افزودن آن سورس به پروژه به عنوان ماژول، روش دیگری نیز وجود دارد که آن، استفاده از سیستم توزیع Gradle است. استفاده از این روش محبوبیت زیادی دارد و بسیار هم راحت‌تر است از افزودن یک سورس به پروژه.

برای افزودن یک ماژول به پروژه از طریق گریدل، به صورت زیر اقدام می‌کنیم:
هر ماژول شامل یک فایل به نام build.gradle است که تنظیمات سطح آن ماژول را به عهده دارد و پروژه نیز یک build.gradle  دارد که تنظیمات آن در سطح پروژه صورت می‌گیرد. برای اقزودن سورس در سطح یک ماژول لازم است که تعدادی خط کد را که معرف و آدرس آن سورس را دارد، به فایل build.gradle اضافه کنیم. به عنوان مثال برای سورس Active Android را که یک ORM عالی در سطح اندروید به شمار می‌آید، به ماژولمان اضافه می‌کنیم:

dependencies {
    compile 'com.michaelpardo:activeandroid:3.1.0-SNAPSHOT'
}
ولی یک سوال پدید می‌آید که این خط کوتاه که تنها شامل نام و نسخه‌ی کتابخانه است، چگونه می‌تواند آدرس آن سورس را به دست بیاورد؟ در این نوشتار قصد داریم این مساله را بررسی کرده و بدانیم که این سورس‌ها چگونه به این سیستم توزیع اضافه شده‌اند.

سوال : اندروید استودیو، کتابخانه‌های اندرویدی را از کجا دانلود می‌کند؟
Apache Maven یک سیستم آزاد است که برای توزیع کتابخانه‌ها مورد استفاده قرار می‌گیرد. سرورهای این سیستم شامل یک مخزن maven هستند که کتابخانه‌ها در آن قرار می‌گیرند و شناسه‌ی دسترسی به آن کتابخانه از طریق همان شناسه‌ای است که شما در build.gradle تعریف می‌کنید. به طور عادی دو سرور استاندارد برای اینکار وجود دارند که یکی از آن‌ها jcenter و دیگری mavenCnteral است. البته سرورهای دیگری نیز وجود دارند، یا اینکه حتی خودتان هم می‌توانید میزبانی را به عهده بگیرید و یا بعضی از شرکت‌ها برای خود مخزنی جداگانه دارند.

JCenter
این سرور که یک مخزن maven است، توسط Bintray میزبانی می‌شود که می‌توانید آن را در این آدرس بیابید. برای اینکه شناسه‌های gradle مربوط به این سرور در اندروید استودیو دانلود شود، نیاز است خط زیر را به build.gradle سطح پروژه اضافه کنید:
allprojects {
    repositories {
        jcenter()
    }
}

MavenCentral
این مخزن توسط Sonatype.org میزبانی می‌شود که کل مخزن آن را می‌توانید در این آدرس بیابید. برای دسترسی به مخازن این سرور نیاز است خطوط زیر را به gradle سطح پروژه اضافه کنید:
allprojects {
    repositories {
        mavenCentral()
    }
}
موقعی که شما شناسه‌ی گریدل را اضافه می‌کنید، حتما باید دقت کنید مخزن آن کجا قرار گرفته است؟ آیا در یکی از آدرس‌های بالاست یا حتی می‌تواند در هر دو آدرس بالا قرار گرفته باشد؛ یا مخزنی غیر از مخازن بالاست.

به عنوان مثال Twitter's Fabric.io خودش کتابخانه‌ی خودش را میزبانی می‌کند و مخزن آن در این آدرس https://maven.fabric.io/public قرار گرفته است و برای افزودن این کتابخانه به پروژه نیاز است مسیر زیر طی شود: 
//project build.gradle
repositories {
    maven { url 'https://maven.fabric.io/public' }
}

//module build.gradle
dependencies {
    compile 'com.crashlytics.sdk.android:crashlytics:2.2.4@aar'
}

سوال : کدامیک از مخازن بالا را انتخاب کنیم؟
اینکه کدامیک را انتخاب کنیم مساله ای است که به خودتان مرتبط است و هر دو برای یک هدف ایجاد شده‌اند و آن میزبانی کتابخانه‌های جاوا و اندرویدی است. بسیاری از توسعه دهندگان از هر دو استفاده می‌کنند؛ ولی بعضی‌ها هم تنها یکی از آن دو را بر می‌گزینند. اندروید استودیو در نسخه‌های اولیه‌ی خود به طور پیش فرض mavencenteral را صدا میزد و به طور پیش فرض در buil.gradle پروژه، آن را معرفی کرده بود. ولی مساله ای که در این بین بود، این بود که این مخزن چندان به مذاق توسعه دهندگان خوش نمی‌آمد و کمی کار با آن دشوار و سخت بود. لذا تیم اندروید بنا به دلایلی مثل آن و موارد امنیتی و ... و اینکه توسعه دهندگان بیرونی بیشتر از jcenter استفاده می‌کردند، آن هم به سمت jcenter رفتند که در ورژن‌های فعلی اندروید استودیو می‌توانید ببینید که کتابخانه‌ی پیش فرض تغییر یافته است و ()jcenter به جای ()mavencentral صدا زده می‌شود.

دلایل مهاجرت از mavencentral به jcenter:

  1. سیستم jcenter از طریق یک CDN عمل می‌کند که در این صورت می‌تواند تجربه‌ی خوبی از سرعت بهتر را برای توسعه دهندگان به همراه داشته باشد.
  2. کتابخانه‌های jcenter بسیار بیشتر از mavencentral هستند؛ تا جایی که می‌توان گفت اکثر کتابخانه‌هایی که روی mavencenteral پیدا می‌شوند، روی jcenter هم هست و jcenter بزرگترین مخزن به شمار می‌آید.
  3. آپلود کتابخانه بر روی jcenter بسیار راحت‌تر است و نیاز به کار پیچیده‌ای ندارد.
در این نوشتار سعی داریم ابتدا کتابخانه‌ی AndroidBreadCrumb را بر روی jcenter آپلود کنیم و سپس با استفاده از روش آسانتری آن را به سمت mavenCentral بفرستیم.

بررسی قسمت‌های یک شناسه Gradle

هر شناسه شامل سه قسمت می‌شود:
GROUP_ID:ARTIFACT_ID:VERSION
قسمت اول نام پکیج است که به آن Group_ID می‌گویند و می‌تواند خانواده‌ای از یک پکیج را نیز مشخص کند. سپس قسمت Artifact، نامی است که بر روی پروژه‌ی خود گذاشته‌اید و سپس ورژن است که در قالب x.y.z معرفی می‌شود و در صورت اختیار می‌توانید عباراتی مثل beta- و snapshot- را هم داشته باشید.
کتابخانه‌های زیر، از یک خانواده هستند که به راحتی می‌توانید آن‌ها را از هم تشخیص دهید:
dependencies {
  compile 'com.squareup:otto:1.3.7'
  compile 'com.squareup.picasso:picasso:2.5.2'
  compile 'com.squareup.okhttp:okhttp:2.4.0'
  compile 'com.squareup.retrofit:retrofit:1.9.0'
}
پس نحوه‌ی دریافت کتابخانه‌ها به این شکل است که ابتدا اندروید استودیو به ترتیب مخازن معرفی شده‌ی در سطح پروژه را چک می‌کند و از طریق شناسه‌ی آن‌ها بررسی می‌کند که آیا این کتابخانه اینجا موجود است، یا خیر و اگر موجود بود آن را دانلود می‌کند.

شناخت فایل‌های AAR
همانطور که می‌دانید فرمت فایل‌های بایت کدی جاوا JAR می‌باشد که هم توسط جاوا و هم اندروید پشتیبانی می‌شود. ولی در صورتیکه کلاس شما یک پروژه‌ی اندرویدی باشد، نمی‌توانید آن را در قالب یک فایل JAR منتشر کنید. چرا که که کلاس اندرویدی می‌تواند شامل فایل مانیفست، منابع و ... باشد که در فایل JAR جایی برای آن‌ها مهیا نشده است. به همین علت فایل‌های نوع AAR برای اینکار مهیا شده‌اند که این فایل در واقع یک فایل زیپ است که محتویات مورد نظر داخل آن قرار گرفته است و یکی از آن فایل Classes.jar برای کدهاست و مابقی آن به شرح زیر است:
- /AndroidManifest.xml (الزامی)
- /classes.jar (الزامی )
- /res/ (الزامی )
- /R.txt (الزامی )
- /assets/ (اختیاری)
- /libs/*.jar (اختیاری )
- /jni/<abi>/*.so (اختیاری )
- /proguard.txt (اختیاری )
- /lint.jar (اختیاری )

در مقاله‌ی بعدی کار را با jcenter آغاز می‌کنیم.
‫۸ سال و ۱۲ ماه قبل، شنبه ۹ آبان ۱۳۹۴، ساعت ۲۳:۳۵
وحید نصیری وحید نصیری
مطالب
تبدیل برنامه‌های کنسول ویندوز به سرویس ویندوز ان تی
در ویژوال استودیو، قالب پروژه ایجاد سرویس‌های ویندوز ان تی از پیش تدارک دیده شده است؛ اما کار کردن با آن ساده نیست به علاوه امکان دیباگ این نوع سرویس‌ها نیز به صورت پیش فرض درنظر گرفته نشده است و نیاز به تمهیدات و نکات خاصی دارد. جهت سهولت ایجاد سرویس‌های ویندوز ان تی، کتابخانه‌ای به نام TopShelf ایجاد شده است که یک برنامه ویندوزی را به سادگی تبدیل به یک سرویس ویندوز ان تی می‌کند. در ادامه جزئیات نحوه استفاده از آن‌را مرور خواهیم کرد.

الف) دریافت TopShelf
TopShelf یک کتابخانه سورس باز است و علاوه بر آن، آخرین فایل‌های باینری آن‌را از طریق نیوگت نیز می‌توان دریافت کرد:
 PM> Install-Package Topshelf


ب) فعال سازی TopShelf
یک برنامه ساده کنسول را ایجاد کنید. سپس با استفاده از نیوگت و اجرای فرمان فوق، ارجاعی را به اسمبلی TopShelf اضافه نمائید.
using Topshelf;

namespace MyService
{
    class Program
    {
        static void Main(string[] args)
        {
            HostFactory.Run(config =>
            {
                config.Service(settings => new TestService());
                config.EnableServiceRecovery(recovery => recovery.RestartService(delayInMinutes: 1));
                config.EnableShutdown();
                config.EnablePauseAndContinue();
                config.SetDescription("MyService Desc.");
                config.SetDisplayName("MyService");
                config.SetServiceName("MyService");
                config.RunAsLocalSystem();
            });
        }
    }
}
کدهای آغازین کار با TopShelf همین چندسطر فوق هستند. در آن وهله‌ای از کلاس سرویس مشتق شده از ServiceControl را دریافت کرده و سپس نام سرویس و سطح دسترسی اجرای آن مشخص می‌شوند. EnableServiceRecovery مربوط به حالتی است که سرویس کرش کرده است و ویندوز این قابلیت را دارد تا یک سرویس را به صورت خودکار راه اندازی مجدد کنند.

using Topshelf;
using Topshelf.Logging;

namespace MyService
{
    public class TestService : ServiceControl
    {
        static readonly LogWriter _log = HostLogger.Get<TestService>();

        public bool Start(HostControl hostControl)
        {
            _log.Info("TestService Starting...");

            return true;
        }

        public bool Stop(HostControl hostControl)
        {
            _log.Info("TestService Stopped");

            return true;
        }

        public bool Pause(HostControl hostControl)
        {
            _log.Info("TestService Paused");

            return true;
        }

        public bool Continue(HostControl hostControl)
        {
            _log.Info("TestService Continued");

            return true;
        }
    }
}
در اینجا امضای کلی کلاس سرویس را مشاهده می‌کند که می‌تواند شامل چهار متد استاندارد آغاز، پایان، مکث و ادامه باشد.


ج) نصب TopShelf

در همین حالت اگر برنامه را اجرا کنید، سرویس ویندوز ان تی تهیه شده، شروع به کار خواهد کرد (مزیت مهم آن نسبت به قالب توکار تهیه سرویس‌های ویندوز در ویژوال استودیو).
برای نصب این سرویس تنها کافی است در خط فرمان با دسترسی مدیریتی، دستور نصب your_exe install و یا عزل your_exe uninstall صادر شوند.
‫۱۰ سال و ۱۱ ماه قبل، شنبه ۲۵ آبان ۱۳۹۲، ساعت ۱۹:۳۰
علیرضا اسم‌رام علیرضا اسم‌رام
مطالب
فشرده سازی فایل های CSS و JavaScript بصورت خودکار توسط MS Ajax Minifier
با توجه به افزایش کاربرد jQuery و دیگر کتابخانه‌های جاوا اسکریپت در برنامه‌های تحت وب، یکی از چالش‌های همیشگی برنامه نویسان، فشرده سازی فایل‌های دربرگیرنده کدهای جاوا اسکریپت و شیوه نامه‌ها  می باشد. برای این منظور راه‌های مختلفی مانند استفاده از ابزارهای آنلاین مانند این +  و این +  وجود دارند. اما یک روش خودکار هم وجود دارد که در زمان Build پروژه‌های دات نت می‌توان از آن بهره گرفت.

Microsoft Ajax Minifier
یک ابزار رایگان جهت فشرده سازی فایل‌های جاوا اسکریپت و شیوه نامه‌ها است. شما می‌توانید این ابزار را از صفحه خانگی آن در سایت asp.net دریافت کنید. جهت استفاده از این ابزار می‌توان از طریق خط فرمان عمل کرد. اما روش ساده‌تر که هدف اصلی این مطلب است به شرح زیر است:
1. در VisualStudio.NET از طریق منو به مسیر Tools, Options, Projects and Solutions بروید و گزینه Always show solution را تیک بزنید.

2. از Solution Explorer بر روی عنوان پروژه کلیک راست کرده و گزینه Unload Project را انتخاب نمایید.

3. مجدداً روی عنوان پروژه کلیک راست کرده و گزینه Edit را انتخاب کنید و دستورات زیر را قبل از بسته شدن تگ Project اضافه کنید:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<Target Name="AfterBuild">
<ItemGroup>
  <JS Include="**\*.js" Exclude="**\*.min.js;Scripts\*.js" />
</ItemGroup>
<ItemGroup>
  <CSS Include="**\*.css" Exclude="**\*.min.css" />
</ItemGroup>
<AjaxMin 
    JsSourceFiles="@(JS)"  JsSourceExtensionPattern="\.js$" JsTargetExtension=".min.js"
    CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".min.css"  />
</Target>
4. دوباره بر روی عنوان پروژه کلیک راست کرده و گزینه Reload Project را انتخاب کنید.
توجه کنید که با این کار ما یک MSBuild task با عنوان ajaxmini به پروژه اضافه کردیم. این وظیفه که در زمان Build پروژه اجرا خواهد شد فایل‌های جاوا اسکریپت را فشرده و با پسوند .min.js و همچنین فایل‌های CSS را پس از فشرده سازی با پسوند .min.css در همان مسیر فایل مادر بطور خودکار ذخیره می‌کند.

نکته:
اگر به دستورات تنظیمات فوق نگاه دقیقتری بیندازیم، متوجه عبارات Include و Exclude می شویم. توسط این دو صفت شما می‌توانید الگوهایی را جهت فشرده سازی و یا عدم فشرده سازی تعریف کنید. بدین معنا که توسط الگوی‌های ذکر شده در تنظیمات فوق از فشرده سازی فایل‌های با پسوند .min.css و .min.js خودداری می‌شود.
در این شرایط در حین توسعه برنامه، شما می‌توانید از فایل‌های با کد خوانا استفاده نمایید و زمان انتشار و Build پروژه بصورت خودکار آنها را با فایل‌های فشرده جایگزین کنید.
این ابزار تمامی فضاهای خالی، ';‌' و '{ }'‌های اضافی و توضیحات را از کدهای شما حذف می‌کند. متغیر‌ها و توابع شما را به اسامی کوجک‌تر تغییر نام می‌دهد. و ...  
همچنین شما از کتابخانه این پروژه می‌توانید در زمان اجرا و سورس برنامه خود استفاده کنید. جهت اطلاعات بیشتر می‌توانید به سایت مربوطه  مراجعه نمایید.
 
‫۱۲ سال و ۴ ماه قبل، پنجشنبه ۲۹ تیر ۱۳۹۱، ساعت ۲۰:۵۹
وحید نصیری وحید نصیری
مطالب
لینک‌های هفته آخر آبان

وبلاگ‌ها و سایت‌های ایرانی


Visual Studio


ASP. Net


طراحی وب


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


به روز رسانی‌ها


سی‌شارپ


عمومی دات نت


PHP


ویندوز


گوگل


متفرقه




‫۱۵ سال و ۱۲ ماه قبل، پنجشنبه ۳۰ آبان ۱۳۸۷، ساعت ۲۳:۵۹
وحید نصیری وحید نصیری
مطالب
استفاده از Google Analytics در ASP.Net

قبل از استفاده از بلاگر، در سایت wordpress وبلاگ داشتم، که به‌دلایلی کنسل شد. تفاوت محسوسی را که اینجا مشاهده می‌کنم، نبود قسمت آمار سایت است. در سایت wordpress آمار مبسوطی را از بازدید کنندگان سایت می‌توانید در کنترل پنل مدیریتی وبلاگ مشاهده کنید، اما در اینجا خیر.
به همین جهت اولین کاری را که انجام دادم استفاده از سرویس رایگان persianstat بود که انصافا هم با کیفیت است و قابل مقایسه با آماری که wordpress ارائه می‌دهد، می‌باشد.
جالب اینجا است که هر چند هاست اینجا، گوگل است اما استفاده‌ی خودکار از ابزار Google analytics در آن مهیا نیست. احتمالا علت آن آماده نبودن API آن است که قرار است به زودی ارائه شود، بنابراین ارزش وقت گذاشتن را دارد.



برای استفاده از Google analytics ، پس از ثبت نام و ورود به آن، سایت مورد نظر را معرفی کرده (در قسمت Add Website Profile) و نهایتا یک کد جاوا اسکریپتی به شما خواهد داد که می‌توانید آنرا به صفحات مورد نظر خود در سایت اضافه نمائید تا تحت کنترل آماری قرار گیرد. محدودیتی هم در مورد تعداد سایت وجود ندارد و با یک اکانت می‌توانید چندین سایت را معرفی کرده و تحت کنترل قرار دهید.
اگر از ASP.Net استفاده می‌کنید، تنها کافی است به master page سایت مراجعه کنید و پیش از بسته شدن تگ body ، اسکریپت مربوط به Google analytics را اضافه کنید تا تمام سایت را تحت کنترل قرار دهید.
یا اگر علاقمند بودید که اینکار را به صورت "شیک‌تری" انجام دهید، می‌توان از این http module استفاده کرد. به این صورت ابتدا تگ بسته شدن body به صورت خودکار پیدا شده و سپس اسکریپت به پیش از آن اضافه می‌شود.
این روش بار بزرگ تهیه آمار سایت را حذف خواهد کرد. عموما دیتابیس جمع آوری آمار سایت خیلی زود (برای مثال پس از گذشت 6 ماه) حجیم می‌شود و تاثیر مشهودی را بر روی کارآیی سایت خواهد گذاشت. بنابراین، این سؤال مطرح می‌شود که چرا گوگل اینکار را برای ما انجام ندهد؟! هزینه بانک اس کیوال سرور بر روی هاست‌های اینترنتی بالا بوده و حجمی را هم که در اختیار قرار می‌دهند محدود است. در صورت نیاز به حجم‌های بالاتر باید هزینه بیشتری را پرداخت کرد. بنابراین هم از لحاظ قیمت و هچنین کارآیی سایت، استفاده از این سرویس واقعا مقرون به صرفه است. بعلاوه از تنوع آماری که ارائه می‌دهد نیز نمی‌توان چشم پوشی کرد. برای مثال کاربران چه واژه‌های کلیدی را در موتورهای جستجو وارد کرده‌اند تا به سایت شما رسیده‌اند؟ چند درصد کاربر وفادار دارید؟! (کاربرهای وفادار، منظور افرادی هستند که به صورت منظم به سایت سر می‌زنند) و امثال این. انصافا تهیه چنین ماژولی برای یک سایت از لحاظ برنامه نویسی شاید با برنامه نویسی کل یک سایت برابری کند.
اگر هم نیاز به یک برنامه سورس باز داشتید که هر روز به اکانت Google analytics شما سر بزند و اطلاعات آنرا استخراج کرده و در یک بانک SQL server ذخیره کند، می‌توانید به پروژه سی شارپ زیر مراجعه نمائید:
Google Analytics Data Extractor

البته باید دقت داشت که پس از ارائه API کامل Google analytics ، دیگر نیازی به این نوع روش‌های ابتکاری وجود نداشته و استخراج داده از آن بسیار ساده‌تر خواهد شد.

‫۱۵ سال و ۱۲ ماه قبل، شنبه ۲ آذر ۱۳۸۷، ساعت ۱۳:۱۱
وحید نصیری وحید نصیری
مطالب
بررسی تغییرات Blazor 8x - قسمت سوم - روش ارتقاء برنامه‌های Blazor Server قدیمی به دات نت 8
در قسمت قبل، با نحوه‌ی رندر سمت سرور و روش فعالسازی قابلیت‌های تعاملی در این حالت، آشنا شدیم. از این نکات می‌توان جهت ارتقاء ساختار پروژه‌های قدیمی Blazor Server به Blazor Server 8x استفاده کرد. البته همانطور که پیشتر نیز عنوان شد، در دات نت 8 دیگر خبری از قالب‌های قدیمی پروژه‌های blazor server و blazor wasm نیست و اگر دقیقا همین موارد مدنظر هستند، آن‌ها را می‌توان با تنظیم سطح رندر و میزان تعاملی که مدنظر است، شبیه سازی کرد و یا حتی هر دو را هم با هم در یک پروژه داشت.


1) به‌روز رسانی شماره نگارش دات‌نت

اولین قدم در جهت ارتقاء پروژه‌های قدیمی، تغییر شماره نگارش TargetFramework موجود در فایل csproj. به net8.0 است. پس از اینکار نیاز است تمام بسته‌های نیوگت موجود را نیز به نگارش‌های جدیدتر آن‌ها ارتقاء دهید.


2) فعالسازی حالت SSR تعاملی سمت سرور

پایه‌ی تمام تغییرات انجام شده‌ی در Blazor 8x، قابلیت SSR است و تمام امکانات دیگر برفراز آن اجرا می‌شوند. به همین جهت پس از ارتقاء شماره نگارش دات‌نت، نیاز است SSR را فعال کنیم و برای اینکار باید به هاست ASP.NET Core بگوئیم که درخواست‌های رسیده را به کامپوننت‌های Razor هدایت کند. بنابراین، به فایل Program.cs مراجعه کرده و دو تغییر زیر را به آن اعمال کنید:
// ...
builder.Services.AddRazorComponents().AddInteractiveServerComponents();
// ...
app.MapRazorComponents<App>().AddInteractiveServerRenderMode();
یک نمونه‌ی کامل از فایل Program.cs را در قسمت قبل مشاهده کردید و یا حتی می‌توانید دستور dotnet new blazor --interactivity Server را جهت ساخت یک پروژه‌ی آزمایشی جدید بر اساس SDK دات نت 8 و ایده گیری از آن، اجرا کنید.

در اینجا ترکیب کامپوننت‌های تعاملی سمت سرور (AddInteractiveServerComponents) و رندر تعاملی سمت سرور (AddInteractiveServerRenderMode)، دقیقا همان Blazor Server قدیمی است که ما با آن آشنا هستیم.

یک نکته: اگر از قالب جدید dotnet new blazor --interactivity None استفاده کنیم، یعنی حالت تعاملی بودن آن‌را به None تنظیم کنیم، کلیات ساختار پروژه‌ای را که مشاهده خواهیم کرد، با حالت تعاملی Server آن یکی است؛ فقط در تنظیمات Program.cs آن، گزینه‌های فوق را نداریم و به صورت زیر ساده شده‌است: 
// ...

builder.Services.AddRazorComponents();

// ...

app.MapRazorComponents<App>();
در این نوع برنامه‌ها نمی‌توان جزایر/قسمت‌های تعاملی Blazor Server را در صفحات و کامپوننت‌های SSR، تعریف کرد. در مورد جزایر تعاملی، در مطالب بعدی بیشتر بحث خواهیم کرد.


3) ایجاد فایل جدید App.razor

در دات نت 8، دیگر خبری از فایل آغازین Host.cshtml_ پروژه‌های Blazor Server قدیمی نیست و کدهای آن با تغییراتی، به فایل جدید App.razor منتقل شده‌اند. در این قسمت، کار هدایت درخواست‌های رسیده به کامپوننت‌های برنامه رخ می‌دهد و از این پس، صفحه‌ی ریشه‌ی برنامه خواهد بود.


در این تصویر، مقایسه‌ای را بین جریان پردازش یک درخواست رسیده در دات نت 8، با نگارش قبلی Blazor Server مشاهده می‌کنید. در دات نت 8، فایل Host.cshtml_ (یک Razor Page آغازین برنامه) با یک کامپوننت Razor به نام App.razor جایگزین شده‌است و فایل قدیمی App.razor این پروژه‌ها به Routes.razor، تغییر نام یافته‌است.

نمونه‌ای از فایل 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>
در این فایل جدید تغییرات زیر رخ داده‌اند:
- تمام دایرکتیوهای تعریف شده مانند page ،@addTagHelper@ و غیره حذف شده‌اند.
- base href تعریف شده اینبار فقط با یک / شروع می‌شود و نه با /~. این مورد خیلی مهم است! اگر به آن دقت نکنید، هیچکدام از فایل‌های استاتیک برنامه مانند فایل‌های css. و js.، بارگذاری نخواهند شد!
- پیشتر برای رندر HeadOutlet، از یک تگ‌هلپر استفاده می‌شد. این مورد در نگارش جدید با یک کامپوننت ساده جایگزین شده‌است.
- تمام component tag helper‌های پیشین حذف شده‌اند و نیازی به آن‌ها نیست.
- ارجاع پیشین فایل blazor.server.js با فایل جدید blazor.web.js جایگزین شده‌است.

یک نکته: همانطور که مشاهده می‌کنید، فایل App.razor یک کامپوننت است و اینبار به همراه تگ <script> نیز شده‌است. یعنی در این نگارش از Blazor می‌توان اسکریپت‌ها را در کامپوننت‌ها نیز ذکر کرد؛ فقط با یک شرط! این کامپوننت حتما باید SSR باشد. اگر این تگ اسکریپتی را در یک کامپوننت تعاملی ذکر کنید، همانند قابل (و نگارش‌های پیشین Blazor) با خطا مواجه خواهید شد.


4) ایجاد فایل جدید Routes.razor و مدیریت سراسری خطاها و صفحات یافت نشده

همانطور که عنوان شد، فایل قدیمی App.razor این پروژه‌ها به Routes.razor تغییر نام یافته‌است که درج آن‌را در قسمت body مشاهده می‌کنید. محتوای این فایل نیز به صورت زیر است:
<Router AppAssembly="@typeof(Program).Assembly">
    <Found Context="routeData">
        <RouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.MainLayout)" />
        <FocusOnNavigate RouteData="@routeData" Selector="h1" />
    </Found>
</Router>
این محتوای جدید، فاقد ذکر کامپوننت NotFound قبلی است؛ از این جهت که سیستم مسیریابی جدید Blazor 8x با ASP.NET Core 8x یکپارچه است و نیازی به این کامپوننت نیست. یعنی اگر قصد مدیریت آدرس‌های یافت نشده‌ی برنامه را دارید، باید همانند ASP.NET Core به صورت زیر در فایل Program.cs عمل کرده:
app.UseStatusCodePagesWithRedirects("/StatusCode/{0}");
و سپس کامپوننت جدید StatusCode.razor را برای مدیریت آن به نحو زیر به برنامه اضافه کنید و بر اساس responseCode دریافتی، واکنش‌های متفاوتی را ارائه دهید:
@page "/StatusCode/{responseCode}"

<h3>StatusCode @ResponseCode</h3>

@code {
    [Parameter] public string? ResponseCode { get; set; }
}

یک نکته: اگر پروژه‌ای را بر اساس قالب dotnet new blazor --interactivity Server ایجاد کنیم، در فایل Program.cs آن، چنین تنظیمی اضافه شده‌است:
if (!app.Environment.IsDevelopment())
{
   app.UseExceptionHandler("/Error", createScopeForErrors: true);
}
که دقیقا معادل رفتاری است که در برنامه‌های ASP.NET Core قابل مشاهده‌است. این مسیر Error/، به کامپوننت جدید Components\Pages\Error.razor نگاشت می‌شود. بنابراین اگر در برنامه‌های جدید Blazor Server، استثنائی رخ دهد، با استفاده از میان‌افزار ExceptionHandler فوق، کامپوننت Error.razor نمایش داده خواهد شد.  باید دقت داشت که این کامپوننت ویژه، تحت هر شرایطی در حالت یک static server component رندر می‌شود.

سؤال: در اینجا (برنامه‌های Blazor Server) چه تفاوتی بین UseExceptionHandler و UseStatusCodePagesWithRedirects وجود دارد؟
میان‌افزار UseExceptionHandler برای مدیریت استثناءهای آغازین برنامه، پیش از تشکیل اتصال دائم SignalR وارد عمل می‌شود. پس از آن و تشکیل اتصال وب‌سوکت مورد نیاز، فقط از میان‌افزار UseStatusCodePagesWithRedirects استفاده می‌کند.
اگر علاقمند نیستید تا تمام خطاهای رسیده را همانند مثال فوق در یک صفحه مدیریت کنید، می‌توانید حداقل سه فایل زیر را به برنامه اضافه کنید تا خطاهای متداول یافت نشدن آدرسی، بروز خطایی و یا عدم دسترسی را مدیریت کنند:

404.razor
@page "/StatusCode/404"

<PageTitle>Not found</PageTitle>

<h1>Not found</h1>
<p role="alert">Sorry, there's nothing at this address.</p>

500.razor
@page "/StatusCode/500"

<PageTitle>Unexpected error</PageTitle>

<h1>Unexpected error</h1>
<p role="alert">There was an unexpected error.</p>

401.razor
@page "/StatusCode/401"

<PageTitle>Not Authorized</PageTitle>

<h1>Not Authorized</h1>
<p role="alert">Sorry, you are not authorized to access this page.</p>


5) تعاملی کردن سراسری برنامه

پس از این تغییرات اگر برنامه را اجرا کنید، بر اساس روش جدید static server-side rendering کار می‌کند و تعاملی نیست. یعنی تمام کامپوننت‌های آن به صورت پیش‌فرض، یکبار بر روی سرور رندر شده و خروجی آن‌ها به مرورگر کاربر ارسال می‌شوند و هیچ اتصال دائم SignalR ای برقرار نخواهد شد. برای فعالسازی سراسری قابلیت‌های تعاملی برنامه و بازگشت به حالت Blazor Server قبلی، به فایل App.razor مراجعه کرده و دو تغییر زیر را اعمال کنید تا به صورت خودکار به تمام زیرکامپوننت‌ها، یعنی کل برنامه، اعمال شود:
<HeadOutlet @rendermode="@InteractiveServer" />
...
<Routes @rendermode="@InteractiveServer" />

نکته 1: اجرای دستور زیر در دات‌نت 8، قالب پروژه‌ای را ایجاد می‌کند که رفتار آن همانند پروژه‌های Blazor Server نگارش‌های قبلی دات‌نت است (این مورد را در قسمت قبل بررسی کردیم)؛ یعنی همه‌جای آن به صورت پیش‌فرض، تعاملی است:
dotnet new blazor --interactivity Server --all-interactive

نکته 2: البته ...  InteractiveServer، دقیقا همان حالت پیش‌فرض برنامه‌های Blazor Server قبلی نیست! این حالت رندر، به صورت پیش‌فرض به همراه پیش‌رندر (pre-rendering) هم هست. یعنی در این حالت، روال رویدادگردان OnInitializedAsync یک کامپوننت، دوبار فراخوانی می‌شود (که باید به آن دقت داشت و عدم توجه به آن می‌تواند سبب انجام دوباره‌ی کارهای سنگین آغازین یک کامپوننت شود)؛ یکبار برای پیش‌رندر صفحه به صورت یک HTML استاتیک (بدون فعال سازی هیچ قابلیت تعاملی) که برای موتورهای جستجو و بهبود SEO مفید است و بار دیگر برای فعالسازی قسمت‌های تعاملی آن، درست پس از زمانیکه اتصال SignalR صفحه، برقرار شد (البته امکان فعالسازی حالت پیش‌رندر در Blazor Server قبلی هم وجود داشت؛ ولی مانند Blazor 8x، به صورت پیش‌فرض فعال نبود). در صورت نیاز، برای سفارشی سازی و لغو آن می‌توان به صورت زیر عمل کرد:
@rendermode InteractiveServerRenderModeWithoutPrerendering

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

در مورد پیش‌رندر و روش مدیریت دوبار فراخوانی شدن روال رویدادگردان OnInitializedAsync یک کامپوننت در این حالت، در قسمت‌های بعدی این سری بیشتر بحث خواهد شد.
 
‫۱۱ ماه قبل، چهارشنبه ۲۴ آبان ۱۴۰۲، ساعت ۰۲:۵۵
وحید نصیری وحید نصیری
مطالب
پیاده سازی Unobtrusive Ajax در ASP.NET Core 1.0
پیاده سازی Unobtrusive Ajax را در ASP.NET MVC 5.x، می‌توانید در مطلب «ASP.NET MVC #21» مطالعه کنید. HTML Helpers مرتبط با Ajax، به طور کامل از ASP.NET Core 1.0 حذف شده‌اند. اما این مورد به این معنا نیست که نمی‌توان Unobtrusive Ajax را در ASP.NET Core که تمرکزش بیشتر بر روی Tag Helpers جدید هست تا HTML Helpers قدیمی، پیاده سازی کرد.


Unobtrusive Ajax چیست؟

در حالت معمولی، با استفاده از متد ajax جی‌کوئری، کار ارسال غیرهمزمان اطلاعات، به سمت سرور صورت می‌گیرد. چون در این روش کدهای جی‌کوئری داخل صفحات برنامه‌های ما قرار می‌گیرند، به این روش، «روش چسبنده» می‌گویند. اما با استفاده از افزونه‌ی «jquery.unobtrusive-ajax.min.js» مایکروسافت، می‌توان این کدهای چسبنده را تبدیل به کدهای غیرچسنبده یا Unobtrusive کرد. در این حالت، پارامترهای متد ajax، به صورت ویژگی‌ها (attributes) به شکل data-ajax به المان‌های مختلف صفحه اضافه می‌شوند و به این ترتیب، افزونه‌ی یاد شده به صورت خودکار با یافتن مقادیر ویژگی‌های data-ajax، این المان‌ها را تبدیل به المان‌های ای‌جکسی می‌کند. در این حالت به کدهایی تمیزتر و عاری از متدهای چسبنده‌ی ajax قرار گرفته‌ی در داخل صفحات وب خواهیم رسید.
روش طراحی Unobtrusive را در کتابخانه‌های معروفی مانند بوت استرپ هم می‌توان مشاهده کرد.


پیشنیازهای فعال سازی Unobtrusive Ajax در ASP.NET Core 1.0

توزیع افزونه‌ی «jquery.unobtrusive-ajax.min.js» مایکروسافت، از طریق bower صورت می‌گیرد که پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 14 - فعال سازی اعتبارسنجی ورودی‌های کاربران» با آن آشنا شدیم. در اینجا نیز برای دریافت آن، تنها کافی است فایل bower.json را به نحو ذیل تکمیل کرد:
{
  "name": "asp.net",
  "private": true,
  "dependencies": {
   "bootstrap": "3.3.6",
   "jquery": "2.2.0",
   "jquery-validation": "1.14.0",
   "jquery-validation-unobtrusive": "3.2.6",
   "jquery-ajax-unobtrusive": "3.2.4"
  }
}
و پس از آن فایل bundleconfig.json مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 21 - بررسی تغییرات Bundling و Minification» یک چنین شکلی را پیدا می‌کند:
[
  {
   "outputFileName": "wwwroot/css/site.min.css",
   "inputFiles": [
    "bower_components/bootstrap/dist/css/bootstrap.min.css",
    "content/site.css"
   ]
  },
  {
   "outputFileName": "wwwroot/js/site.min.js",
   "inputFiles": [
    "bower_components/jquery/dist/jquery.min.js",
    "bower_components/jquery-validation/dist/jquery.validate.min.js",
    "bower_components/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js",
    "bower_components/jquery-ajax-unobtrusive/jquery.unobtrusive-ajax.min.js",
    "bower_components/bootstrap/dist/js/bootstrap.min.js"
   ],
   "minify": {
    "enabled": true,
    "renameLocals": true
   },
   "sourceMap": false
  }
]
در اینجا فایل‌های css و اسکریپت مورد نیاز برنامه، به ترتیب اضافه شده و یکی خواهند شد. خروجی نهایی آن‌ها به شکل زیر در صفحات وب مورد استفاده قرار می‌گیرند:
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>@ViewBag.Title - My ASP.NET Application</title>
    <link href="~/css/site.min.css" rel="stylesheet" />
</head>
<body>
    <div>
        <div>
                @RenderBody()
        </div>
    </div>

    <script src="~/js/site.min.js" type="text/javascript" asp-append-version="true"></script>
    @RenderSection("Scripts", required: false)
</body>
</html>
در اینجا تنها دو فایل نهایی این عملیات، یعنی css/site.min.css و js/site.min.js به صفحه الحاق شده‌اند که حاوی تمام پیشنیازهای اسکریپتی و شیوه‌نامه‌های برنامه هستند و در این حالت دیگر نیاز به افزودن آن‌ها به دیگر صفحات سایت نیست.


استفاده از معادل‌های واقعی Unobtrusive Ajax در ASP.NET Core 1.0

واقعیت این است که HTML Helper ای‌جکسی حذف شده‌ی از ASP.NET Core 1.0، کاری بجز افزودن ویژگی‌های data-ajax را که توسط افزونه‌ی jquery.unobtrusive-ajax.min.js پردازش می‌شوند، انجام نمی‌دهد و این افزونه مستقل است از مباحث سمت سرور و به نگارش خاصی از ASP.NET گره نخورده است. بنابراین در اینجا تنها کاری را که باید انجام داد، استفاده از همان ویژگی‌های اصلی است که این افزونه قادر به شناسایی آن‌ها است.
خلاصه‌ی آن‌ها را جهت انتقال کدهای قدیمی و یا تهیه‌ی کدهای جدید، در جدول ذیل می‌توانید مشاهده کنید:

 HTML attribute   AjaxOptions 
 data-ajax-confirm   Confirm 
 data-ajax-method   HttpMethod 
 data-ajax-mode   InsertionMode 
 data-ajax-loading-duration   LoadingElementDuration 
 data-ajax-loading   LoadingElementId 
 data-ajax-begin   OnBegin 
 data-ajax-complete   OnComplete 
 data-ajax-failure   OnFailure 
 data-ajax-success   OnSuccess 
 data-ajax-update   UpdateTargetId 
 data-ajax-url   Url 
   
در ASP.NET Core 1.0، به علت حذف متدهای کمکی Ajax دیگر خبری از AjaxOptions نیست. اما اگر علاقمند به انتقال کدهای قدیمی به ASP.NET Core 1.0 هستید، معادل‌های اصلی این پارامترها را می‌توانید در ستون HTML attribute مشاهده کنید.

چند نکته:
- اگر قصد استفاده‌ی از این ویژگی‌ها را دارید، باید ویژگی "data-ajax="true را نیز حتما قید کنید تا سیستم Unobtrusive Ajax فعال شود.
- ویژگی data-ajax-mode تنها با ذکر data-ajax-update (و یا همان UpdateTargetId پیشین) معنا پیدا می‌کند.
- ویژگی data-ajax-loading-duration نیاز به ذکر data-ajax-loading (و یا همان LoadingElementId پیشین) را دارد.
- ویژگی data-ajax-mode مقادیر before، after و replace-with را می‌پذیرد. اگر قید نشود، کل المان با data دریافتی جایگزین می‌شود.
- سه callback قابل تعریف data-ajax-complete، data-ajax-failure و data-ajax-success، یک چنین پارامترهایی را از سمت سرور در اختیار کلاینت قرار می‌دهند:

parameters  
 Callback  
 xhr, status   data-ajax-complete 
 data, status, xhr   data-ajax-success 
 xhr, status, error   data-ajax-failure 

برای مثال می‌توان ویژگی data-ajax-success را به نحو ذیل در سمت کلاینت مقدار دهی کرد:
 data-ajax-success = "myJsMethod"
این متد جاوا اسکریپتی یک چنین امضایی را دارد:
  function myJsMethod(data, status, xhr) {
}
در این حالت در سمت سرور، پارامتر data در یک اکشن متد، به صورت ذیل مقدار دهی می‌شود:
 return Json(new { param1 = 1, param2 = 2, ... });
و در سمت کلاینت در متد myJsMethod این پارامترها را به صورت data.param1 می‌توان دریافت کرد.


مثال‌هایی از افزودن ویژگی‌های data-ajax به المان‌های مختلف

 در حالت استفاده از Form Tag Helpers که در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 12 - معرفی Tag Helpers» بررسی شدند، یک فرم ای‌جکسی، چنین تعاریفی را پیدا خواهد کرد:
با این ViewModel فرضی
using System.ComponentModel.DataAnnotations;
 
namespace Core1RtmEmptyTest.ViewModels.Account
{
    public class RegisterViewModel
    {
        [Required]
        [EmailAddress]
        [Display(Name = "Email")]
        public string Email { get; set; }
    }
}
که در View متناظر Ajax ایی ذیل استفاده شده‌است:
@using Core1RtmEmptyTest.ViewModels.Account
@model RegisterViewModel
@{
}
 
<form method="post"
      asp-controller="TestAjax"
      asp-action="Index"
      asp-route-returnurl="@ViewBag.ReturnUrl"
      class="form-horizontal"
      role="form"
      data-ajax="true"
      data-ajax-loading="#Progress"
      data-ajax-success="myJsMethod">
 
    <input asp-for="Email" class="form-control" />
    <span asp-validation-for="Email" class="text-danger"></span>
 
    <button type="submit">ارسال</button>
 
    <div id="Progress" style="display: none">
        <img src="images/loading.gif" alt="loading..." />
    </div>
</form>
 
@section scripts{
    <script type="text/javascript">
        function myJsMethod(data, status, xhr) {
            alert(data.param1);
        }
    </script>
}
در اینجا تمام تعاریف مانند قبل است؛ تنها سه ویژگی data-ajax جهت فعال سازی jquery-ajax-unobtrusive به فرم اضافه شده‌اند. همچنین یک callback دریافت پیام موفقیت آمیز بودن عملیات Ajax ایی نیز تعریف شده‌است.

این View از کنترلر ذیل استفاده می‌کند:
using Core1RtmEmptyTest.ViewModels.Account;
using Microsoft.AspNetCore.Mvc;
 
namespace Core1RtmEmptyTest.Controllers
{
    public class TestAjaxController : Controller
    {
 
        public IActionResult Index()
        {
            return View();
        }
 
        [HttpPost]
        public IActionResult Index([FromForm]RegisterViewModel vm)
        {
            var ajax = isAjax();
            if (ajax)
            {
                // it's an ajax post
            }
 
 
            if (ModelState.IsValid)
            {
                //todo: save data
 
                return Json(new { param1 = 1, param2 = 2 });
            }
            return View();
        }
 
        private bool isAjax()
        {
            return Request?.Headers != null && Request.Headers["X-Requested-With"] == "XMLHttpRequest";
        }
    }
}
به ASP.NET Core 1.0، متد کمکی IsAjax اضافه نشده‌است؛ اما تعریف آن‌را در این کنترلر مشاهده می‌کنید. در مورد قید FromForm در ادامه توضیح داده خواهد شد (هرچند در این مورد خاص، حالت پیش فرض است و الزامی به قید آن نیست).

و یا Action Link ای‌جکسی نیز به صورت خلاصه به این نحو قابل تعریف است:
<div id="EmployeeInfo">
<a 
 asp-controller="MyController" asp-action="MyAction"
 data-ajax="true" 
 data-ajax-loading="#Progress" 
 data-ajax-method="POST" 
 data-ajax-mode="replace" 
 data-ajax-update="#EmployeeInfo">
 Get Employee-1 info
</a>

  <div id="Progress" style="display: none">
    <img src="images/loading.gif" alt="loading..."  />
  </div>
</div>


نکته‌ای در مورد اکشن متدهای ای‌جکسی در ASP.NET Core 1.0

همانطور که در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 18 - کار با ASP.NET Web API»، قسمت «تغییرات Model binding پیش فرض، برای پشتیبانی از ASP.NET MVC و ASP.NET Web API» نیز ذکر شد: 
public IActionResult Index([FromBody] MyViewModel vm)
{
   return View();
}
ذکر ویژگی FromBody در اینجا الزامی است. از این جهت که اطلاعات با فرمت JSON، از قسمت body درخواست استخراج و به MyViewModel بایند خواهند شد (در حالت dataType: json). و اگر dataType : application/x-www-form-urlencoded; charset=utf-8 بود (مانند حالت پیش فرض Unobtrusive Ajax)، باید از ویژگی FromForm استفاده شود. در غیر اینصورت در سمت سرور نال دریافت خواهیم کرد.
‫۸ سال قبل، پنجشنبه ۱۵ مهر ۱۳۹۵، ساعت ۱۵:۴۵
وحید نصیری وحید نصیری
مطالب
آشنایی با آزمایش واحد (unit testing) در دات نت، قسمت 2

دلایل شانه خالی کردن از آزمایش واحد!

1- نوشتن آزمایشات زمان زیادی را به خود اختصاص خواهند داد.

مهمترین دلیلی که برنامه‌نویس‌ها به سبب آن از نوشتن آزمایشات واحد امتناع می‌کنند، همین موضوع است. اکثر افراد به آزمایش به‌عنوان مرحله آخر توسعه فکر می‌کنند. اگر این چنین است، بله! نوشتن آزمایش‌های واحد واقعا سخت و زمانگیر خواهند بود. به همین جهت برای جلوگیری از این مساله روش pay-as-you-go مطرح شده است (ماخذ: کتاب Pragmatic Unit Testing در سی شارپ). یعنی با اضافه شدن هر واحد کوچکی به سیستم، آزمایش واحد آن‌را نیز تهیه کنید. به این صورت در طول توسعه سیستم با باگ‌های کمتری نیز برخورد خواهید داشت چون اجزای آن‌را در این حین به تفصیل مورد بررسی قرار داده‌اید. اثر این روش را در شکل زیر می‌توانید ملاحظه نمائید (تصویری از همان کتاب ذکر شده)




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

بنابراین اگر عنوان می‌کنید که وقت ندارید آزمایش واحد بنویسید، به چند سؤال زیر پاسخ دهید:
الف) چه مقدار زمان را صرف دیباگ کردن کدهای خود یا دیگران می‌کنید؟
ب) چه میزان زمان را صرف بازنویسی کدی کرده‌اید که تصور می‌رفت درست کار می‌کند اما اکنون بسیار مشکل زا ظاهر شده است؟
ج) چه مقدار زمان را صرف این کرده‌اید که منشاء باگ گزارش شده در برنامه را کشف کنید؟

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



تصویری از کتاب xUnit Test Patterns ، که بیانگر کاهش زمان و هزینه کد نویسی در طول زمان با رعایت اصول آزمایشات واحد است

2- اجرای آزمایشات واحد زمان زیادی را تلف می‌کند.

نباید اینطور باشد. عموما اجرای هزاران آزمایش واحد، باید در کسری از ثانیه صورت گیرد. (برای اطلاعات بیشتر به قسمت حد و مرز یک آزمایش واحد در قسمت قبل مراجعه نمائید)

3- امکان تهیه آزمایشات واحد برای کدهای قدیمی ( legacy code ) من وجود ندارد

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

4- کار من نیست که کدهای نوشته شده را آزمایش کنم!

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

5- تنها قسمتی از سیستم به من واگذار شده است و من دقیقا نمی‌دانم که رفتار کلی آن چیست. بنابراین آن را نمی‌توانم آزمایش کنم!

اگر واقعا نمی‌دانید که این کد قرار است چه کاری را انجام دهید به طور قطع الان زمان مناسبی برای کد نویسی آن نیست!

6- کد من کامپایل می‌شود!

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

7- من برای نوشتن آزمایشات حقوق نمی‌گیرم!

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

8- احساس گناه خواهم کرد اگر تیم فنی کنترل کیفیت و آزمایشات را از کار بی کار کنم!!

نگران نباشید، این اتفاق نخواهد افتاد! بحث ما در اینجا آزمایش کوچکترین اجزا و واحدهای یک سیستم است. موارد دیگری مانند functional testing, acceptance testing, performance & environmental testing, validation & verification, formal analysis توسط تیم‌های کنترل کیفیت و آزمایشات هنوز باید بررسی شوند.

9- شرکت من اجازه اجرای آزمایشات واحد را بر روی سیستم‌های در حال اجرا نمی‌دهد.

قرار هم نیست بدهد! چون دیگر نام آن آزمایش واحد نخواهد بود. این آزمایشات باید بر روی سیستم شما و توسط ابزار و امکانات شما صورت گیرد.


پ.ن.
در هشتمین دلیل ذکر شده، از acceptance testing نامبرده شده. تفاوت آن با unit testing به صورت زیر است:

آزمایش واحد:
توسط برنامه نویس‌ها تعریف می‌شود
سبب اطمینان خاطر برنامه نویس‌ها خواهد شد
واحدهای کوچک سیستم را مورد بررسی قرار می‌دهد
یک آزمایش سطح پائین ( low level ) به شمار می‌رود
بسیار سریع اجرا می‌شود
به صورت خودکار (100 درصد خودکار است) و با برنامه نویسی قابل کنترل است

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


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

‫۱۵ سال و ۱۱ ماه قبل، یکشنبه ۸ دی ۱۳۸۷، ساعت ۱۷:۱۶
وحید نصیری وحید نصیری
نظرات مطالب
استفاده از Fluent Validation در برنامه‌های ASP.NET Core - قسمت چهارم - اعتبارسنجی Async سمت کلاینت و یا همان Remote Client Side Validation
اعتبارسنجی، یک «cross-cutting concern» هست و نباید با «business logic» مخلوط شود. برای مدیریت «cross-cutting concern»ها عموما از روش‌های AOP استفاده می‌شود؛ مانند قرار دادن یک Attribute بر روی متدی که قرار است پیش از اجرای منطق اصلی این متد، اجرا شود (الگوی decorator). در اینجا هم اجرای اعتبارسنجی‌ها دقیقا به همین صورت است. پیش از رسیدن به متدهای سرویس برنامه، به صورت خودکار، کار اجرای اعتبارسنجی آن‌ها انجام می‌شود.
یک نمونه‌ی از جداسازی‌های «cross-cutting concern»‌ها در مطلب «Validating with a Service Layer» خود مایکروسافت قابل مشاهده‌است. ابتدا با قرار دادن کل منطق اعتبارسنجی در داخل یک سرویس شروع کرده و سپس این منطق را refactor کرده و تبدیل به یک سرویس مجزای قابل استفاده‌ی در یک سرویس و یا کنترلر در آورده. البته آن مطلب عمومی است و هر دوی این‌ها با Fluent validation، چه به صورت اعمال خودکار و یا اجرای دستی، قابل انجام است.
در کل پیاده سازی اعتبارسنجی business logic، توسط specification pattern انجام می‌شود؛ دقیقا مانند تعاریف AbstractValidatorها در Fluent validation (که پیاده سازی specification pattern هستند) و عموما اجرای آن‌ها به دلیل cross-cutting concern بودن، توسط decorator pattern صورت می‌گیرد؛ مانند روش‌های سوم و چهارم اجرای AbstractValidatorها.
‫۴ سال و ۳ ماه قبل، دوشنبه ۱۶ تیر ۱۳۹۹، ساعت ۱۶:۵۲
مهرداد کاهه مهرداد کاهه
نظرات مطالب
پیاده سازی یک سیستم دسترسی Role Based در Web API و AngularJs - بخش سوم (پایانی)
در پاسخ به سوال شما باید عرض کنم که حرف شما کاملا درست است. به این دلیل که با هر فراخوانی از سمت کلاینت لیست permissionهای کاربر واکشی میشود. برای کم کردن این فراخوانی‌ها و واکشی‌ها ما چند راه در پیش رو خواهیم داشت.
1. استفاده از  caching اولین راه حل و ساده‌ترین راه حل هست. به این صورت که در هنگامی که کاربر وارد برنامه میشود تمامی دسترسی‌های او در cache ذخیره شود. برای این کار نیاز به نوشتن سرویسی برای مدیریت این حافظه است. فرض کنید در این حین دسترسی نقشی که کاربر در آن نقش است تغییر کند. بنابراین باید تمامی cache از نو ایجاد شود. توجه کنید که ما نمیتوانیم در معماری REST و Web API از Session استفاده کنیم. به این دلیل که فرایندها در این معماری Stateless هستند، به این معنی که چیزی را در خود نگه نمیدارند.
2. روش دیگر استفاده از Claim در Asp.Net Identity 2 است. در سیستم Identity جدید Asp شما قادر هستید چندین Claim برای کاربر تنظیم (set) کنید. برای این کار میتوانید مقاله ای در این زمینه را از سایت bitOfTech مطالعه کنید. در این مجموعه  مقالات تشریح شده است که چگونه میتوان Claim‌های شخصی سازی شده در سیستم تعریف کرد. در نهایت این Claimها hash شده و در Token کاربر ذخیره میشوند. توصیه میکنم اگر تعداد دسترسی‌های شما در هر نقش زیاد نیست میتوانید از این روش استفاده کنید. البته این را مد نظر داشته باشید در این مقالات نحوه Authorize کردن کاربر با آنچه ما در این مجموعه مقالات تشریح کردیم کمی متفاوت است. 
‫۸ سال و ۵ ماه قبل، دوشنبه ۲۷ اردیبهشت ۱۳۹۵، ساعت ۱۷:۰۵