# Use Pattern Matching to Avoid ‘As’ Followed by A ‘Null’ Check dotnet_diagnostic.IDE0019.severity = warning
{ "Logging": { "LogLevel": { "Default": "Information", "Microsoft": "Warning", "Microsoft.Hosting.Lifetime": "Information" }, "EventLog": { // here ... "LogLevel": { "Default": "Information" //Trace, Debug } } } }
راه اندازی StimulSoft Report در ASP.NET MVC
آشنایی با NUnit
NUnit یکی از فریم ورکهای آزمایش واحد سورس باز مخصوص دات نت فریم ورک است. (کلا در دات نت هرجایی دیدید که N ، به ابتدای برنامهای یا کتابخانهای اضافه شده یعنی نمونه منتقل شده از محیط جاوا به دات نت است. برای مثال NHibernate از Hibernate جاوا گرفته شده است و الی آخر)
این برنامه با سی شارپ نوشته شده است اما تمامی زبانهای دات نتی را پشتیبانی میکند (اساسا با زبان نوشته شده کاری ندارد و فایل اسمبلی برنامه را آنالیز میکند. بنابراین فرقی نمیکند که در اینجا چه زبانی بکار گرفته شده است).
ابتدا NUnit را دریافت نمائید:
http://nunit.org/index.php?p=download
یک برنامه ساده از نوع console را در VS.net آغاز کنید.
کلاس MyList را با محتوای زیر به پروژه اضافه کنید:
using System.Collections.Generic;
namespace sample
{
public class MyList
{
public static List<int> GetListOfIntItems(int numberOfItems)
{
List<int> res = new List<int>();
for (int i = 0; i < numberOfItems; i++)
res.Add(i);
return res;
}
}
}
اکنون بر روی نام پروژه در قسمت solution explorer کلیک راست کرده و گزینه add->new project را انتخاب کنید. نوع این پروژه را که متدهای آزمایش واحد ما را تشکیل خواهد داد، class library انتخاب کنید. با نام مثلا TestLibrary (شکل زیر).
با توجه به اینکه NUnit ، اسمبلی برنامه (فایل exe یا dll آنرا) آنالیز میکند، بنابراین میتوان پروژه تست را جدای از پروژه اصلی ایجاد نمود و مورد استفاده قرار داد.
پس از ایجاد پروژه class library ، باید ارجاعی از NUnit framework را به آن اضافه کنیم. به محل نصب NUnit مراجعه کرده (پوشه bin آن) و ارجاعی به فایل nunit.framework.dll را به پروژه اضافه نمائید (شکل زیر).
سپس فضاهای نام مربوطه را به کلاس آزمایش واحد خود اضافه خواهیم کرد:
using NUnit.Framework;
using NUnit.Framework.SyntaxHelpers;
سپس باید ویژگی جدیدی به نام TestFixture را به این کلاس اضافه کرد.
[TestFixture]
public class TestClass
سپس هر متدی که به عنوان متد آزمایش واحد نوشته میشود، باید دارای ویژگی Test باشد تا توسط NUnit بررسی گردد:
[Test]
public void TestGetListOfIntItems()
اکنون برای اینکه بتوانیم متد GetListOfIntItems برنامه خود را در پروژه دیگری تست کنیم، باید ارجاعی را به اسمبلی آن اضافه کنیم. همانند قبل، از منوی project گزینه add reference ، فایل exe برنامه کنسول خود را انتخاب کرده و ارجاعی از آنرا به پروژه class library اضافه میکنیم. بدیهی است امکان اینکه کلاس تست در همان پروژه هم قرار میگرفت وجود داشت و صرفا جهت جداسازی آزمایش از برنامه اصلی اینکار صورت گرفت.
پس از این مقدمات، اکنون متد آزمایش واحد ساده زیر را در نظر بگیرید:
[Test]
public void TestGetListOfIntItems()
{
const int count = 5;
List<int> items = sample.MyList.GetListOfIntItems(count);
Assert.That(items.Count,Is.EqualTo(5));
}
اگر آن را (سطر مربوط به Assert را) کلمه به کلمه بخواهیم به فارسی ترجمه کنیم به صورت زیر خواهد بود:
میخواهیم اثبات کنیم که count مربوط به شیء items مساوی 5 است.
پس از اضافه کردن متد فوق، پروژه را کامپایل نمائید.
اکنون برنامه nunit.exe را اجرا کنید تا NUnit IDE ظاهر شود (در همان دایرکتوری bin مسیر نصب NUnit قرار دارد).
از منوی File آن یک پروژه جدید را آغاز نموده و آنرا ذخیره کنید.
سپس از منوی project آن، با استفاده از گزینه add assembly ، فایل dll کتابخانه تست خود را اضافه نمائید.
احتمالا پس از انجام این عملیات بلافاصله با خطای زیر مواجه خواهید شد:
---------------------------
Assembly Not Loaded
---------------------------
System.ApplicationException : Unable to load TestLibrary because it is not located under
the AppBase
----> System.IO.FileNotFoundException : Could not load file or assembly
'TestLibrary' or one of its dependencies. The system cannot find the file specified.
For further information, use the Exception Details menu item.
همانطور که ملاحظه میکنید، NUnit با استفاده از قابلیتهای reflection در دات نت، اسمبلی را بارگذاری میکند و تمامی کلاسهایی که دارای ویژگی TestFixture باشند در آن لیست خواهد شد.
اکنون بر روی دکمه run کلیک کنید تا اولین آزمایش ما انجام شود. (شکل زیر)
رنگ سبز در اینجا به معنای با موفقیت انجام شدن آزمایش است.
ادامه دارد...
مرتب سازی پراکسیها در سرویسهای WCF
فرض کنید یک پراکسی دینامیک (dynamic proxy) از یک کوئری دریافت کرده اید. حال میخواهید این پراکسی را در قالب یک آبجکت CLR سریال کنید. هنگامی که آبجکتهای موجودیت را بصورت POCO-based پیاده سازی میکنید، EF بصورت خودکار یک آبجکت دینامیک مشتق شده را در زمان اجرا تولید میکند که dynamix proxy نام دارد. این آبجکت برای هر موجودیت POCO تولید میشود. این آبجکت پراکسی بسیاری از خواص مجازی (virtual) را بازنویسی میکند تا عملیاتی مانند ردیابی تغییرات و بارگذاری تنبل را انجام دهد.
فرض کنید مدلی مانند تصویر زیر دارید.
ما از کلاس ProxyDataContractResolver برای deserialize کردن یک آبجکت پراکسی در سمت سرور و تبدیل آن به یک آبجکت POCO روی کلاینت WCF استفاده میکنیم. مراحل زیر را دنبال کنید.
- در ویژوال استودیو پروژه جدیدی از نوع WCF Service Application بسازید. یک Entity Data Model به پروژه اضافه کنید و جدول Clients را مطابق مدل مذکور ایجاد کنید.
- کلاس POCO تولید شده توسط EF را باز کنید و کلمه کلیدی virtual را به تمام خواص اضافه کنید. این کار باعث میشود EF کلاسهای پراکسی دینامیک تولید کند. کد کامل این کلاس در لیست زیر قابل مشاهده است.
public class Client { public virtual int ClientId { get; set; } public virtual string Name { get; set; } public virtual string Email { get; set; } }
نکته: بیاد داشته باشید که هرگاه مدل EDMX را تغییر میدهید، EF بصورت خودکار کلاسهای موجودیتها را مجددا ساخته و تغییرات مرحله قبلی را بازنویسی میکند. بنابراین یا باید این مراحل را هر بار تکرار کنید، یا قالب T4 مربوطه را ویرایش کنید. اگر هم از مدل Code-First استفاده میکنید که نیازی به این کارها نخواهد بود.
- ما نیاز داریم که DataContractSerializer از یک کلاس ProxyDataContractResolver استفاده کند تا پراکسی کلاینت را به موجودیت کلاینت برای کلاینت سرویس WCF تبدیل کند. یعنی client proxy به client entity تبدیل شود، که نهایتا در اپلیکیشن کلاینت سرویس استفاده خواهد شد. بدین منظور یک ویژگی operation behavior میسازیم و آن را به متد ()GetClient در سرویس الحاق میکنیم. برای ساختن ویژگی جدید از کدی که در لیست زیر آمده استفاده کنید. بیاد داشته باشید که کلاس ProxyDataContractResolver در فضای نام Entity Framework قرار دارد.
using System.ServiceModel.Description; using System.ServiceModel.Channels; using System.ServiceModel.Dispatcher; using System.Data.Objects; namespace Recipe8 { public class ApplyProxyDataContractResolverAttribute : Attribute, IOperationBehavior { public void AddBindingParameters(OperationDescription description, BindingParameterCollection parameters) { } public void ApplyClientBehavior(OperationDescription description, ClientOperation proxy) { DataContractSerializerOperationBehavior dataContractSerializerOperationBehavior = description.Behaviors .Find<DataContractSerializerOperationBehavior>(); dataContractSerializerOperationBehavior.DataContractResolver = new ProxyDataContractResolver(); } public void ApplyDispatchBehavior(OperationDescription description, DispatchOperation dispatch) { DataContractSerializerOperationBehavior dataContractSerializerOperationBehavior = description.Behaviors .Find<DataContractSerializerOperationBehavior>(); dataContractSerializerOperationBehavior.DataContractResolver = new ProxyDataContractResolver(); } public void Validate(OperationDescription description) { } } }
- فایل IService1.cs را باز کنید و کد آن را مطابق لیست زیر تکمیل نمایید.
[ServiceContract] public interface IService1 { [OperationContract] void InsertTestRecord(); [OperationContract] Client GetClient(); [OperationContract] void Update(Client client); }
- فایل IService1.svc.cs را باز کنید و پیاده سازی سرویس را مطابق لیست زیر تکمیل کنید.
public class Client { [ApplyProxyDataContractResolver] public Client GetClient() { using (var context = new EFRecipesEntities()) { context.Cofiguration.LazyLoadingEnabled = false; return context.Clients.Single(); } } public void Update(Client client) { using (var context = new EFRecipesEntities()) { context.Entry(client).State = EntityState.Modified; context.SaveChanges(); } } public void InsertTestRecord() { using (var context = new EFRecipesEntities()) { // delete previous test data context.ExecuteSqlCommand("delete from [clients]"); // insert new test data context.ExecuteStoreCommand(@"insert into [clients](Name, Email) values ('Armin Zia','armin.zia@gmail.com')"); } } }
- حال پروژه جدیدی از نوع Console Application به راه حل جاری اضافه کنید. این اپلیکیشن، کلاینت تست ما خواهد بود. پروژه سرویس را ارجاع کنید و کد کلاینت را مطابق لیست زیر تکمیل نمایید.
using Recipe8Client.ServiceReference1; namespace Recipe8Client { class Program { static void Main(string[] args) { using (var serviceClient = new Service1Client()) { serviceClient.InsertTestRecord(); var client = serviceClient.GetClient(); Console.WriteLine("Client is: {0} at {1}", client.Name, client.Email); client.Name = "Armin Zia"; client.Email = "arminzia@live.com"; serviceClient.Update(client); client = serviceClient.GetClient(); Console.WriteLine("Client changed to: {0} at {1}", client.Name, client.Email); } } } }
Client changed to: Armin Zia at arminzia@live.com
شرح مثال جاری
مایکروسافت استفاده از آبجکتهای POCO با WCF را توصیه میکند چرا که مرتب سازی (serialization) آبجکت موجودیت را سادهتر میکند. اما در صورتی که از آبجکتهای POCO ای استفاده میکنید که changed-based notification دارند (یعنی خواص موجودیت را با virtual علامت گذاری کرده اید و کلکسیونهای خواص پیمایشی از نوع ICollection هستند)، آنگاه EF برای موجودیتهای بازگشتی کوئریها پراکسیهای دینامیک تولید خواهد کرد.
استفاده از پراکسیهای دینامیک با WCF دو مشکل دارد. مشکل اول مربوط به سریال کردن پراکسی است. کلاس DataContractSerializer تنها قادر به serialize/deserialize کردن انواع شناخته شده (known types) است. در مثال جاری این یعنی موجودیت Client. اما از آنجا که EF برای موجودیتها پراکسی میسازد، حالا باید آبجکت پراکسی را سریال کنیم، نه خود کلاس Client را. اینجا است که از DataContractResolver استفاده میکنیم. این کلاس میتواند حین سریال کردن آبجکت ها، نوعی را به نوع دیگر تبدیل کند. برای استفاده از این کلاس ما یک ویژگی سفارشی ساختیم، که پراکسیها را به کلاسهای POCO تبدیل میکند. سپس این ویژگی را به متد ()GetClient اضافه کردیم. این کار باعث میشود که پراکسی دینامیکی که توسط متد ()GetClient برای موجودیت Client تولید میشود، به درستی سریال شود.
مشکل دوم استفاده از پراکسیها با WCF مربوط به بارگذاری تبل یا Lazy Loading میشود. هنگامی که DataContractSerializer موجودیتها را سریال میکند، تمام خواص موجودیت را دستیابی خواهد کرد که منجر به اجرای lazy-loading روی خواص پیمایشی میشود. مسلما این رفتار را نمیخواهیم. برای رفع این مشکل، مشخصا قابلیت بارگذاری تنبل را خاموش یا غیرفعال کرده ایم.
معرفی کتابخانه InfiniteEnumFlags
Enumهای دات نت با [Flags] attribute, ویژگی قدرتمندی است که امکان ذخیره و ترکیب چندین گزینه یا Feature را تنها به صورت یک مقدار ثابت فراهم میکند که از طریق Bitwise operatorها میتوانیم به ترکیب چندین Enum بپردازیم و یا از طریق این مقدار ثابت به تک تک اعضای تشکیل دهنده آن برسیم. ولی مشکل بزرگی این این ویژگی دارد محدودیت آن است که برای Enum هایی از نوع int تنها 32 آیتم و از نوع long تنها 64 مورد را پشتیبانی میکند. این مشکل سبب میشود در اکثر سناریوها به سراغ این ویژگی نرویم,
به طور مثال برای تعریف دسترسیهای یک نرم افزار به صورت Strongly Type به احتمال زیاد با بزرگتر شدن برنامه در آینده به مشکل برخورد میکنیم.
InfiniteEnumFlags کتابخانه کوچکی است که تمام امکانات [Flags] را در اختیار ما میگذارد و میتواند حدود 2.1 میلیارد آیتم را پشتیبانی کند.
public class Permission : InfiniteEnum<Permission> { public static readonly Flag<Permission> None = new(-1); public static readonly Flag<Permission> ViewRoles = new(0); public static readonly Flag<Permission> ManageRoles = new(1); public static readonly Flag<Permission> ViewUsers = new(2); public static readonly Flag<Permission> ManageUsers = new(3); public static readonly Flag<Permission> ConfigureAccessControl = new(4); public static readonly Flag<Permission> Counter = new(5); public static readonly Flag<Permission> Forecast = new(6); public static readonly Flag<Permission> ViewAccessControl = new(7); // We can support up to 2,147,483,647 items }
مثال استفاده از آن برای تعریف سطح دسترسیها در برنامههای Asp.net core در فولدر Example این مخزن میتوانید پیدا کنید.
git clone --recurse-submodules https://github.com/alirezanet/InfiniteEnumFlags.git
تزریق وابستگیهای AutoMapper در لایه سرویس برنامه
- محل فراخوانی اولیهی تعاریف نگاشتها جهت معرفی آنها به سیستم، مهم است.
+ اگر از کاربر اطلاعاتی را دریافت میکنید، در لایه UI هست که کار نگاشت اطلاعات دریافتی از کاربر و از ViewModelها به Modelهای اصلی برنامه انجام میشود (توسط متد Mapper.Map). اگر قرار است اطلاعاتی را بازگشت دهید، متدهای جدیدی مانند Project To بسیار بهینهتر هستند از روش قدیمی Mapper.Map و این متد را بهتر است در لایه سرویس استفاده کنید. متد Project To کارش بهینه سازی کوئری SQL ارسالی به سرور هست. اگر از روش Mapper.Map در لایه UI استفاده کنید، این قابلیت را از دست خواهید داد؛ چون Mapper.Map به معنای کار با اشیاء درون حافظه و LINQ to Objects است. کار متد ویژهی Project To افزونهای برای کار با Entity Framework و بهینه سازی آن است.
<img [src]="...." />
<img [ngClass]='..' />
import { Directive, ElementRef, OnInit } from '@angular/core'; @Directive({ selector: '[appHighlight]', }) export class HighlightDirective implements OnInit { _dval = 'green'; constructor(private _ref: ElementRef) { } ngOnInit(): void { this._ref.nativeElement.style.backgroundColor = this._dval; } }
<span appHighlight>Attibute Directive</span>
حال ممکن است که بخواهید به این ویژگی مقداری را نسبت دهید و از طریق این مقدار، عملیات مورد نظر را انجام دهید. به عنوان نمونه در اینجا میخواهیم رنگ پس زمینه را در همان تگ معرفی کنیم:
پس کلاس دایرکتیو را به شکل زیر بازنویسی میکنیم:
import { Directive, ElementRef, OnInit } from '@angular/core'; @Directive({ selector: '[appHighlight]', inputs: ["hc"] }) export class HighlightDirective implements OnInit { hc: string; _dval = 'green'; constructor(private _ref: ElementRef) { } ngOnInit(): void { this._ref.nativeElement.style.backgroundColor = this.hc || this._dval; } }
معرفی کردن یک فیلد به عنوان ورودی در انگیولار، از دو طریق امکان پذیر است:
1. در اولین حالت شما متغیری را تعریف میکنید و آن متغیر را همانند کد بالا داخل ویژگی inputs متادیتای Directive معرفی میکنید.
2. در شیوه بعد که در این مقاله هم ذکر شده است میتوانید از طریق متادیتایی به نام Input@ اینکار را انجام دهید:
@Input() hc:string;
اینکه از کدام شیوه استفاده کنید تفاوتی ندارد و به خودتان بستگی دارد. ولی شیوهی اول به دلیل اینکه همه یکجا تعریف میشوند، نظم بهتری داشته و در یک نگاه میتوان ورودیها را تشخیص داد؛ ولی در شیوهی دوم باید کل کلاس را برای یافتن آنها مشاهده کرد.
مزیت روش دوم این است که در حین کدنویسی بسیار راحت است تا در همانجا ورودی را تعریف کنیم؛ به جای اینکه مرتب به ابتدای کلاس بازگردیم تا آن را تعریف کنیم.
this._ref.nativeElement.style.backgroundColor=this.hc || this._dval;
<h1 appHighlight [hc]="'red'"> َApp Works! </h1>
<h1 appHighlight [hc]="'red'" [hc2]="....." [hc3]="....." ....> App Works! </h1>
گاهی اوقات ممکن است بخواهید عمل مورد نظر را بر اساس رویدادهای یک المان انجام دهید. پس کلاس را مجددا بازنویسی کرده و کدهای جدید را به آن اضافه میکنیم:
import { Directive, ElementRef, OnInit } from '@angular/core'; @Directive({ selector: '[appHighlight]', inputs: ["hc"], host: { '(mouseenter)': 'onMouseEnter()', '(mouseleave)': 'onMouseLeave()', } }) export class HighlightDirective implements OnInit { hc: string; _dval = 'green'; constructor(private _ref: ElementRef) {} ngOnInit(): void { this._ref.nativeElement.style.backgroundColor = this.hc || this._dval; } onMouseEnter() { this._ref.nativeElement.style.backgroundColor = 'blue'; } onMouseLeave() { this._ref.nativeElement.style.backgroundColor = 'pink'; } }