اشتراکها
اشتراکها
خلاصهای از C# 6 در یک صفحه
در سری مقالات پیاده سازی CQRS توسط کتابخانه MediatR، مطالبی جهت آشنایی و نحوه استفاده از این کتابخانه بیان شدهاست که در بخش چهارم، به رفتارها (Behavior)ها جهت اعمالی از جمله اعتبارسنجی، ثبت وقایع و ... پرداخته شدهاست. در این مقاله قصد داریم با استفاده از رفتارها، اقدام به پیاده سازی کش، برای خروجی حاصل از کوئریها نماییم.
با توجه به اینکه برای کش کردن دادهها، نیاز به یک کلید منحصر بفرد داریم، اینترفیس فوق، داری یک خصوصیت رشتهای Key میباشد و تمامی درخواستهایی که نیاز به کش کردن دارند، باید Key را با یک مقدار منحصر بفرد مقدار دهی کنند. در کدهای پایین، یک نمونه از یک درخواست را مشاهده میکنید که مقدار Key را برابر با نام کلاس، به همراه شناسه رکورد مورد نظر مقدار دهی کردهاست:
همانطور که قابل مشاهدهاست، ابتدا کش با مقدار کلید درخواست جاری بررسی میشود و اگر مقداری در کش موجود باشد همان را بر میگرداند، در غیر این صورت هندلر مربوطه اجرا خواهد شد و سپس مقدار دریافت شده از خروجی هندلر را کش خواهد کرد.
با استفاده از رفتارها، تمامی کدهای لازم برای خواندن و ثبت دادهها از کش، در Behavior مربوطه پیاده سازی خواهد شد و نیازی نیست در تمامی هندلرهای مربوط به درخواستهای از نوع Query، کدهای مربوط به Caching تکرار شود.
ابتدا یک interface همانند زیر ایجاد خواهیم کرد و هدف از آن، محدود کردن Caching برای درخواستهایی خواهد بود که از این اینترفیس ارث بری کردهاند و نه تمامی درخواستها:
public interface ICachableQuery { public string Key { get;} }
public class GetBookmarkQuery : IRequest<BookmarkDto>, ICachableQuer { public int Id { get; init; } public string Key => $"{nameof(GetBookmarkQuery)}-{Id}"; public GetBookmarkQuery(int id) { Id = id; } }
و در ادامه، یک Behavior به اسم Caching Behavior ایجاد و کدهای لازم برای خواندن و ثبت دادهها از کش را پیاده سازی کردهایم:
public class CachingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse> where TRequest : ICachableQuer { private readonly IDistributedCache _cache; public CachingBehavior(IDistributedCache distributedCache) { _cache = distributedCache; } public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next) { TResponse response; var cachedResponse = await _cache.GetAsync(request.Key, cancellationToken); if (cachedResponse != null) response = JsonConvert.DeserializeObject<TResponse>(Encoding.Default.GetString(cachedResponse)); else { response = await next(); var serialized = Encoding.Default.GetBytes(JsonConvert.SerializeObject(response)); await _cache.SetAsync(request.Key, serialized, cancellationToken); } return response; } }
و در پایان نیاز هست این Behavior را به صورت زیر ثبت نماییم :
services.AddScoped(typeof(IPipelineBehavior<,>), typeof(CachingBehavior <,>));
با توجه با اینکه ممکن است بعد از کش کردن خروجی یک کوئری، تغییراتی بر روی رکورد مورد نظر که کش شده است انجام شود، بهتر است تاریخ انقضا برای کشها ثبت شود و یا بعد از به روزرسانی یک رکورد، کش مربوطه را به روزرسانی کنید.
نحوه پیاده سازی و مدیریت Instance در پروژههای مبتنی بر WCF
نکته : آشنایی اولیه با مفاهیم WCF جهت درک صحیح مطالب الزامی است.
تشریح مسئله : در صورتی که نیاز باشد که نمونه ساخته شده از سرویس (سمت سرور) به صورت Singleton باشد بهترین روش برای پیاده سازی به چه صورت است.
برای شروع ابتدا مثال زیر را پیاده سازی میکنیم.
یک Contract به صورت زیر تعریف میکنیم:
حالا یک سرویس برای پیاده سازی Interface بالا مینویسیم.
همانطور که از نام سرویس مشخص است از این سرویس به ازای هر فراخوانی یک نمونه سمت سرور ساخته میشود.
حالا برای مشاهده نتیجه یک پروژه ConsoleApplication ایجاد کنید و سرویس مورد نظر را از روش AddServiceReference به پروژه اضافه کرده در فایل Program کدهای زیر را کپی کنید.
بعد از اجرا خروجی به صورت زیر است:
تنها تفاوت این سرویس با سرویس قبلی در این است که InstanceContextMode این سرویس به صورت Single معرفی شده است. یعنی به ازای n فراخوانی فقط یک نمونه از کلاس ساخته میشود. این سرویس رو هم مثل روش قبلی به Client Application اضافه کنید.
کد کلاس Program رو به صورت زیر تغییر دهید.
که بعد از اجرا خروجی به صورت زیر است.
نکته : آشنایی اولیه با مفاهیم WCF جهت درک صحیح مطالب الزامی است.
تشریح مسئله : در صورتی که نیاز باشد که نمونه ساخته شده از سرویس (سمت سرور) به صورت Singleton باشد بهترین روش برای پیاده سازی به چه صورت است.
برای شروع ابتدا مثال زیر را پیاده سازی میکنیم.
یک Contract به صورت زیر تعریف میکنیم:
[ServiceContract(SessionMode=SessionMode.Allowed)] public interface IMyService { [OperationContract] int GetData(); }
حالا یک سرویس برای پیاده سازی Interface بالا مینویسیم.
[ServiceBehavior( InstanceContextMode = InstanceContextMode.PerCall )] public class PerCallService : IMyService { int count; public int GetData() { return ++count; } }
حالا برای مشاهده نتیجه یک پروژه ConsoleApplication ایجاد کنید و سرویس مورد نظر را از روش AddServiceReference به پروژه اضافه کرده در فایل Program کدهای زیر را کپی کنید.
static void Main( string[] args ) { Console.WriteLine( "PerCall Service" ); MyPerCallService.MyServiceClient client = new MyPerCallService.MyServiceClient(); int count = 0; for ( int i = 0 ; i < 5 ; i++ ) { count = client.GetData(); } Console.WriteLine( count ); Console.ReadLine(); }
بعد از 5 بار فراخوانی متد GetData باز خروجی دارای مقدار 1 است. یعنی به ازای هر بار فراخوانی متد GetData یک نمونه از سرویس مورد نظر ساخته میشود.این عمل توسط خصوصیت InstanceContextMode که از نوع PerCall است به سرویس اعمال میشود.
حالا یک سرویس دیگر به صورت زیر ایجاد کنید.
[ServiceBehavior( InstanceContextMode = InstanceContextMode.Single )] public class SingleService : IMyService { int count; public int GetData() { return ++count; } }
کد کلاس Program رو به صورت زیر تغییر دهید.
static void Main( string[] args ) { Console.WriteLine( "Single Service" ); MySingleService.MyServiceClient client = new MySingleService.MyServiceClient(); int count = 0; for ( int i = 0 ; i < 5 ; i++ ) { count = client.GetData(); } Console.WriteLine("Result is : {0}", count ); Console.ReadLine(); }
به ازای 5 بار فراخوانی سرویس متغیر Count سمت سرور مقدار قبلی خود را حفظ کرده است.
مفهوم «ابزارها» و یا «project tools» از نگارش اول NET Core. به همراه آن است؛ مانند تنظیم زیر در فایل csproj برنامهها:
که سبب فعالسازی ابزار dotnet ef میشود و توسط آن میتوان دستورات dotnet ef database update و یا dotnet ef migrations add را بر روی پروژهی جاری اجرا کرد. در این حالت برنامه dotnet.exe، هاست اجرایی این ابزارهای محلی و مختص به یک پروژه است.
این ایده نیز از npm و ابزارهای محلی و مختص به یک پروژهی آن گرفته شدهاست. اما npm امکان نصب این ابزارها را به صورت سراسری نیز دارد که امکان وجود linters ، test runners و یا development web servers را میسر کردهاست و در این حالت نیازی نیست یک چنین ابزارهایی را به ازای هر پروژه نیز یکبار نصب کرد.
معرفی ابزارهای سراسری در NET Core 2.1.
اگر SDK جدید NET Core 2.1 را نصب کرده باشید، پس از Build یک پروژهی مبتنی بر NET Core 2.0. (که توسط فایل global.json، شماره SDK آن محدود و مقید نشدهاست) یک چنین پیامهای اخطاری را مشاهده خواهید کرد:
یکی از ویژگیهای جدید NET Core 2.1 معرفی global tools یا ابزارهای سراسری آن است. هدف از آن، تهیه برنامههای کنسول مبتنی بر NET Core. است که توسط NuGet توزیع و به روز رسانی میشوند. توسعه دهندگان جاوا اسکریپت با یک چنین مفهومی تحت عنوان ابزارهای سراسری NPM آشنا هستند (NPM global tools)؛ همان سوئیچ g- که یک ابزار جاوا اسکریپتی را به صورت سراسری نصب میکند؛ مانند کامپایلر TypeScript.
پیامهای اخطار فوق نیز به این معنا هستند که دیگر نیازی نیست تا برای اجرای دستور dotnet watch run، حتما ابزار پروژهی Microsoft.DotNet.Watcher.Tools را به صورت دستی به تمام فایلهای csproj خود اضافه کنید. ابزار Watcher و یا EntityFrameworkCore.Tools اکنون جزو ابزارهای سراسری NET Core 2.1. هستند و بدون نیازی به افزودن ارجاع خاصی به آنها، هم اکنون در تمام پروژههای NET Core. شما قابل دسترسی و استفاده هستند. بنابراین ارجاعات مستقیم به آنها را حذف کنید؛ چون غیرضروری میباشند.
روش نصب ابزارهای سراسری در NET Core.
روش نصب ابزارهای سراسری NET Core. به صورت زیر است:
با این دستور، برنامهی فرضی example از نیوگت دریافت شده و ابتدا در یکی از دو پوشهی زیر، فایل فشرده شدهی آن باز خواهد شد:
و سپس در ویندوز، در مسیر زیر قرار خواهد گرفت (محل نصب نهایی):
این مسیر در لینوکس به صورت زیر است:
در حال حاضر برای عزل این برنامهها باید به یکی از این مسیرها مراجعه و آنها را دستی حذف کرد (در هر دو مسیر toolspkgs و tools باید حذف شوند).
یک نمونه از این ابزارها را که dotnet-dev-certs نام دارد، پس از نصب SDK جدید، در مکانهای یاد شده، خواهید یافت. کار این ابزار سراسری، تولید یک self signed certificate مخصوص برنامههای ASP.NET Core 2.1 است که پیشتر در مطلب «اجبار به استفادهی از HTTPS در حین توسعهی برنامههای ASP.NET Core 2.1» آنرا بررسی کردیم.
نکته 1: بر اساس تصویر فوق، در خط فرمان، دستور dotnet-dev-certs را صادر کنید. اگر پیام یافت نشدن این دستور یا ابزار را مشاهده کردید، به معنای این است که مسیر نصب آنها به PATH سیستم اضافه نشدهاست. با استفاده از دستورات ذیل میتوانید این مسیر را به PATH سیستم اضافه کنید:
نکته 2: اگر به این مسیرها دقت کنید، این ابزارها صرفا برای کاربر جاری سیستم نصب میشوند و مختص به او هستند؛ به عبارتی user-specific هستند و نه machine global.
روش ایجاد ابزارهای سراسری NET Core.
همانطور که عنوان شد، ابزارهای سراسری NET Core. در اصل برنامههای کنسول آن هستند. به همین جهت پس از نصب SDK جدید، در یک پوشهی جدید، دستور dotnet new console را اجرا کنید تا یک برنامهی کنسول جدید مطابق آن ایجاد شود. سپس فایل csproj آنرا به صورت زیر ویرایش کنید:
در اینجا دو خاصیت IsPackable و PackAsTool جدید بوده و مختص به ابزارهای سراسری NET Core. هستند. تنظیم همین دو خاصیت برای تبدیل یک برنامهی کنسول معمولی به ابزار سراسری کافی است.
پس از آن برای تهیهی یک بستهی نیوگت از آن، دستور زیر را اجرا کنید:
پس از ارسال فایل nupkg حاصل به سایت نیوگت، کاربران آن میتوانند توسط دستور زیر آنرا نصب کنند:
<ItemGroup> <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" /> </ItemGroup>
این ایده نیز از npm و ابزارهای محلی و مختص به یک پروژهی آن گرفته شدهاست. اما npm امکان نصب این ابزارها را به صورت سراسری نیز دارد که امکان وجود linters ، test runners و یا development web servers را میسر کردهاست و در این حالت نیازی نیست یک چنین ابزارهایی را به ازای هر پروژه نیز یکبار نصب کرد.
معرفی ابزارهای سراسری در NET Core 2.1.
اگر SDK جدید NET Core 2.1 را نصب کرده باشید، پس از Build یک پروژهی مبتنی بر NET Core 2.0. (که توسط فایل global.json، شماره SDK آن محدود و مقید نشدهاست) یک چنین پیامهای اخطاری را مشاهده خواهید کرد:
warning : Using DotNetCliToolReference to reference 'Microsoft.EntityFrameworkCore.Tools.DotNet' is obsolete and can be removed from this project. This tool is bundled by default in the .NET Core SDK. warning : Using DotNetCliToolReference to reference 'Microsoft.DotNet.Watcher.Tools' is obsolete and can be removed from this project. This tool is bundled by default in the .NET Core SDK.
پیامهای اخطار فوق نیز به این معنا هستند که دیگر نیازی نیست تا برای اجرای دستور dotnet watch run، حتما ابزار پروژهی Microsoft.DotNet.Watcher.Tools را به صورت دستی به تمام فایلهای csproj خود اضافه کنید. ابزار Watcher و یا EntityFrameworkCore.Tools اکنون جزو ابزارهای سراسری NET Core 2.1. هستند و بدون نیازی به افزودن ارجاع خاصی به آنها، هم اکنون در تمام پروژههای NET Core. شما قابل دسترسی و استفاده هستند. بنابراین ارجاعات مستقیم به آنها را حذف کنید؛ چون غیرضروری میباشند.
روش نصب ابزارهای سراسری در NET Core.
روش نصب ابزارهای سراسری NET Core. به صورت زیر است:
dotnet tool install -g example
%USERPROFILE%\.dotnet\toolspkgs (Windows) $HOME/.dotnet/toolspkgs (macOS/Linux)
%USERPROFILE%\.dotnet\tools
~/.dotnet/tools
در حال حاضر برای عزل این برنامهها باید به یکی از این مسیرها مراجعه و آنها را دستی حذف کرد (در هر دو مسیر toolspkgs و tools باید حذف شوند).
یک نمونه از این ابزارها را که dotnet-dev-certs نام دارد، پس از نصب SDK جدید، در مکانهای یاد شده، خواهید یافت. کار این ابزار سراسری، تولید یک self signed certificate مخصوص برنامههای ASP.NET Core 2.1 است که پیشتر در مطلب «اجبار به استفادهی از HTTPS در حین توسعهی برنامههای ASP.NET Core 2.1» آنرا بررسی کردیم.
نکته 1: بر اساس تصویر فوق، در خط فرمان، دستور dotnet-dev-certs را صادر کنید. اگر پیام یافت نشدن این دستور یا ابزار را مشاهده کردید، به معنای این است که مسیر نصب آنها به PATH سیستم اضافه نشدهاست. با استفاده از دستورات ذیل میتوانید این مسیر را به PATH سیستم اضافه کنید:
Windows PowerShell: setx PATH "$env:PATH;$env:USERPROFILE/.dotnet/tools" Linux/macOS: echo "export PATH=\"\$PATH:\$HOME/.dotnet/tools\"" >> ~/.bash_profile
نکته 2: اگر به این مسیرها دقت کنید، این ابزارها صرفا برای کاربر جاری سیستم نصب میشوند و مختص به او هستند؛ به عبارتی user-specific هستند و نه machine global.
روش ایجاد ابزارهای سراسری NET Core.
همانطور که عنوان شد، ابزارهای سراسری NET Core. در اصل برنامههای کنسول آن هستند. به همین جهت پس از نصب SDK جدید، در یک پوشهی جدید، دستور dotnet new console را اجرا کنید تا یک برنامهی کنسول جدید مطابق آن ایجاد شود. سپس فایل csproj آنرا به صورت زیر ویرایش کنید:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <IsPackable>true</IsPackable> <PackAsTool>true</PackAsTool> <TargetFramework>netcoreapp2.1</TargetFramework> </PropertyGroup> </Project>
پس از آن برای تهیهی یک بستهی نیوگت از آن، دستور زیر را اجرا کنید:
dotnet pack -c Release
dotnet tool install -g package-name
مطالب دورهها
ساخت یک Mini ORM با AutoMapper
Mini ORMها برخلاف ORMهای کاملی مانند Entity framework یا NHibernate، کوئریهای LINQ را تبدیل به SQL نمیکنند. در اینجا کار با SQL نویسی مستقیم شروع میشود و مهمترین کار این کتابخانهها، نگاشت نتیجهی دریافتی از بانک اطلاعاتی به اشیاء دات نتی هستند. خوب ... AutoMapper هم دقیقا همین کار را انجام میدهد! بنابراین در ادامه قصد داریم یک Mini ORM را به کمک AutoMapper طراحی کنیم.
کلاس پایه AdoMapper
در اینجا کلاس پایه Mini ORM طراحی شده را ملاحظه میکنید. برای نمونه قسمت GetRecords آن مانند مباحث استاندارد ADO.NET است. فقط کار خواندن و همچنین نگاشت رکوردهای دریافت شده از بانک اطلاعاتی به شیءایی از نوع T توسط AutoMapper انجام خواهد شد.
نحوهی استفاده از کلاس پایه AdoMapper
در کدهای ذیل نحوهی ارث بری از کلاس پایه AdoMapper و سپس استفاده از متدهای آنرا ملاحظه میکنید:
در این مثال نحوهی تعریف کوئریهای پارامتری نیز در متد GetById به نحو متداولی مشخص شدهاست. کار نگاشت حاصل این کوئریها به اشیاء دات نتی را AutoMapper انجام خواهد داد. نحوهی کار نیز، نگاشت فیلد f1 به خاصیت f1 است (هم نامها به هم نگاشت میشوند).
تعریف پروفایل مخصوص AutoMapper
ORMهای تمام عیار، کار نگاشت فیلدهای بانک اطلاعاتی را به خواص اشیاء دات نتی، به صورت خودکار انجام میدهند. در اینجا همانند روشهای متداول کار با AutoMapper نیاز است این نگاشت را به صورت دستی یکبار تعریف کرد:
و سپس در ابتدای برنامه آنرا به AutoMapper معرفی نمود:
سفارشی سازی نگاشتهای AutoMapper
فرض کنید کلاس Advertisement زیر، معادل است با جدول Advertisements بانک اطلاعاتی؛ با این تفاوت که در کلاس تعریف شده، خاصیت TitleWithOtherName تطابقی با هیچکدام از فیلدهای بانک اطلاعاتی ندارد. بنابراین اطلاعاتی نیز به آن نگاشت نخواهد شد.
برای رفع این مشکل میتوان حین تعریف پروفایل مخصوص Advertisement، آنرا سفارشی سازی نیز نمود:
در اینجا پس از تعریف نگاشت مخصوص کار با IDataRecordها، عنوان شدهاست که هر زمانیکه به خاصیت TitleWithOtherName رسیدی، مقدارش را از فیلد Title دریافت و جایگزین کن.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
کلاس پایه AdoMapper
public abstract class AdoMapper<T> where T : class { private readonly SqlConnection _connection; protected AdoMapper(string connectionString) { _connection = new SqlConnection(connectionString); } protected virtual IEnumerable<T> ExecuteCommand(SqlCommand command) { command.Connection = _connection; command.CommandType = CommandType.StoredProcedure; _connection.Open(); try { var reader = command.ExecuteReader(); try { return Mapper.Map<IDataReader, IEnumerable<T>>(reader); } finally { reader.Close(); } } finally { _connection.Close(); } } protected virtual T GetRecord(SqlCommand command) { command.Connection = _connection; _connection.Open(); try { var reader = command.ExecuteReader(); try { reader.Read(); return Mapper.Map<IDataReader, T>(reader); } finally { reader.Close(); } } finally { _connection.Close(); } } protected virtual IEnumerable<T> GetRecords(SqlCommand command) { command.Connection = _connection; _connection.Open(); try { var reader = command.ExecuteReader(); try { return Mapper.Map<IDataReader, IEnumerable<T>>(reader); } finally { reader.Close(); } } finally { _connection.Close(); } } }
نحوهی استفاده از کلاس پایه AdoMapper
در کدهای ذیل نحوهی ارث بری از کلاس پایه AdoMapper و سپس استفاده از متدهای آنرا ملاحظه میکنید:
public class UsersService : AdoMapper<User>, IUsersService { public UsersService(string connectionString) : base(connectionString) { } public IEnumerable<User> GetAll() { using (var command = new SqlCommand("SELECT * FROM Users")) { return GetRecords(command); } } public User GetById(int id) { using (var command = new SqlCommand("SELECT * FROM Users WHERE Id = @id")) { command.Parameters.Add(new SqlParameter("id", id)); return GetRecord(command); } } }
تعریف پروفایل مخصوص AutoMapper
ORMهای تمام عیار، کار نگاشت فیلدهای بانک اطلاعاتی را به خواص اشیاء دات نتی، به صورت خودکار انجام میدهند. در اینجا همانند روشهای متداول کار با AutoMapper نیاز است این نگاشت را به صورت دستی یکبار تعریف کرد:
public class UsersProfile : Profile { protected override void Configure() { this.CreateMap<IDataRecord, User>(); } public override string ProfileName { get { return this.GetType().Name; } } }
Mapper.Initialize(cfg => // In Application_Start() { cfg.AddProfile<UsersProfile>(); });
سفارشی سازی نگاشتهای AutoMapper
فرض کنید کلاس Advertisement زیر، معادل است با جدول Advertisements بانک اطلاعاتی؛ با این تفاوت که در کلاس تعریف شده، خاصیت TitleWithOtherName تطابقی با هیچکدام از فیلدهای بانک اطلاعاتی ندارد. بنابراین اطلاعاتی نیز به آن نگاشت نخواهد شد.
public class Advertisement { public int Id { set; get; } public string Title { get; set; } public string Description { get; set; } public int UserId { get; set; } public string TitleWithOtherName { get; set; } }
public class AdvertisementsProfile : Profile { protected override void Configure() { this.CreateMap<IDataRecord, Advertisement>() .ForMember(dest => dest.TitleWithOtherName, options => options.MapFrom(src => src.GetString(src.GetOrdinal("Title")))); } public override string ProfileName { get { return this.GetType().Name; } } }
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
در قسمت قبل، نگاهی داشتیم به 4 نوع مختلف data binding در AngularJS 2.0. در قسمت جاری میخواهیم کیفیت کدهای کامپوننت لیست محصولات را با strong typing بهبود بخشیده و همچنین چرخهی حیات کامپوننتها را به همراه ایجاد custom pipes بررسی کنیم.
افزودن strong typing به کامپوننت نمایش لیست محصولات
یکی از مزایای کار با TypeScript امکان انتساب نوعهای مشخص یا سفارشی، به متغیرها و اشیاء تعریف شدهاست. برای مثال تاکنون هر خاصیت تعریف شدهای دارای نوع است. اما هنوز نوعی را برای آرایهی محصولات تعریف نکردهایم و نوع آن، نوع پیش فرض any است که برخلاف رویهی متداول کار با TypeScript است.
برای تعریف نوعهای سفارشی میتوان از اینترفیسهای TypeScript استفاده کرد. یک اینترفیس، قراردادی است که نحوهی تعریف تعدادی خاصیت و متد به هم مرتبط را مشخص میکند. سپس کلاسهای مختلف میتوانند با پیاده سازی این اینترفیس، قرارداد تعریف شدهی در آن را عملی کنند. همچنین از اینترفیسها میتوان به عنوان یک data type جدید نیز استفاده کرد. البته ES 5 و ES 6 از اینترفیسها پشتیبانی نمیکنند و تعریف آنها در TypeScript صرفا جهت کمک به کامپایلر، برای یافتن خطاها، پیش از اجرای برنامه است و به کدهای جاوا اسکریپتی معادلی ترجمه نمیشوند.
در ادامه برای تکمیل مثال این سری، فایل جدید App\products\product.ts را به پروژه اضافه کنید؛ با این محتوا:
یک اینترفیس، با واژهی کلیدی interface تعریف شده و سپس نام آن تعریف میشود. مرسوم است این نام با I شروع شود؛ هرچند الزامی نیست و در بسیاری از اینترفیسهای AngularJS 2.0 از این روش نامگذاری استفاده نشدهاست.
همچنین از آنجائیکه این اینترفیس را در یک فایل ts مجزا قرار دادهایم، برای اینکه بتوان از آن در سایر قسمتهای برنامه استفاده کرد، نیاز است در ابتدای آن، واژهی کلیدی export را نیز ذکر کرد.
پس از تعریف این اینترفیس، برای استفاده از آن به عنوان یک data type جدید، ابتدا ماژول آن import خواهد شد و سپس از نام آن به عنوان نوع دادهی جدیدی، استفاده میشود. برای این منظور فایل product-list.component.ts را گشوده و تغییرات ذیل را به آن اعمال کنید:
در اینجا ابتدا IProduct را import و سپس بجای any، نوع جدید IProduct را جهت مشخص سازی نوع آرایهی products تعریف کردهایم.
مزیت اینکار این است که برای مثال در اینجا اگر در لیست اعضای آرایهی products، نام خاصیتی اشتباه تایپ شده باشد یا حتی بجای عدد، از رشته استفاده شده باشد، بلافاصله در ادیتور مورد استفاده، خطای مرتبط گوشزد شده و همچنین این فایل دیگر کامپایل نخواهد شد. به علاوه اینبار برای تعریف خواص اعضای آرایهی products، ادیتور مورد استفاده، intellisense را نیز دراختیار ما قرار میدهد و کاملا مشخص است که چه اعضایی مدنظر هستند و نوع آنها چیست.
مدیریت cssهای هر کامپوننت به صورت مجزا
هنگام ساخت یک قالب یا template، در بسیاری از اوقات نیاز است css مرتبط با آن نیز، منحصر به همان قالب بوده و نشتی نداشته باشد. برای مثال زمانیکه یک کامپوننت را درون کامپوننتی دیگر قرار میدهیم، باید css آن نیز در دسترس قرار بگیرد و css فعلی کامپوننت دربرگیرنده را بازنویسی نکند. روشهای مختلفی برای مدیریت این مساله وجود دارند:
الف) تعریف شیوه نامهها به صورت inline داخل خود قالبها. این حالت، مشکلات نگهداری و استفادهی مجدد را دارد.
ب) تعریف شیوه نامهها در یک فایل خارجی css و سپس لینک کردن آن به صفحهای اصلی یا index.html
در این حالت به ازای هر فایل، یکبار باید این تعریف در صفحهای اصلی سایت صورت گیرد. همچنین این فایلها میتوانند مقادیر یکدیگر را بازنویسی کرده و بر روی هم تاثیر بگذارند.
ج) تعریف شیوه نامهها به همراه تعریف کامپوننت. این روشی است که توسط AngularJS توصیه شدهاست و نگهداری و مقیاس پذیری آن سادهتر است.
تزئین کنندهی Component به همراه دو خاصیت دیگر به نامهای styles و stylesUrl نیز میباشد.
در حالت استفاده از خاصیت styles، شیوهنامهی متناظر با کامپوننت، در همانجا به صورت inline تعریف میشود:
همانطور که مشاهده میکنید، خاصیت styles به صورت یک آرایه تعریف شدهاست و امکان پذیرش چندین شیوه نامهی جدا شدهی با کاما را دارد.
روش بهتر، استفاده از خاصیت styleUrls است که در آن میتوان مسیر یک یا چند فایل css را مشخص کرد:
این خاصیت نیز یک آرایه را میپذیرد و در اینجا میتوان مسیر چندین فایل css را در صورت نیاز ذکر کرد.
برای آزمایش آن فایل جدید product-list.component.css را به پوشهی products مثال این سری اضافه کنید؛ با این محتوا:
سپس لینک این فایل را به مجموعه خواص کامپوننت لیست محصولات (product-list.component.ts) اضافه میکنیم:
در این حالت اگر برنامه را اجرا کنید، رنگ سرستونهای جدول محصولات به نحو ذیل تغییر کردهاند:
یک نکته
شیوه نامهای که به این صورت توسط AngularJS 2.0 اضافه میشود، با سایر شیوه نامههای موجود تداخل نخواهد کرد. علت آنرا در تصویر ذیل که با استفاده از developer tools مرورگرها قابل بررسی است، میتوان مشاهده کرد:
در اینجا AngularJS 2.0، با ایجاد ویژگیهای سفارشی خودکار (attributes) میدان دید css را کنترل میکند. به این ترتیب شیوه نامهی کامپوننت یک، که درون کامپوننت دو قرار گرفتهاست، نشتی نداشته و بر روی سایر قسمتهای صفحه تاثیری نخواهد گذاشت؛ برخلاف شیوه نامههایی که به صورت متداولی به صفحهی اصلی سایت لینک شدهاند.
بررسی چرخهی حیات کامپوننتها
هر کامپوننت دارای چرخهی حیاتی است که توسط AngularJS 2.0 مدیریت میشود و شامل مراحلی مانند ایجاد، رندر، ایجاد و رندر فرزندان آن، پردازش تغییرات آن و در نهایت تخریب آن کامپوننت میشود. برای اینکه بتوان با برنامه نویسی به این مراحل چرخهی حیات یک کامپوننت دسترسی یافت، تعدادی life cycle hook طراحی شدهاند. سه مورد از مهمترین life cycle hooks شامل موارد ذیل هستند:
الف) OnInit: از این hook برای انجام کارهای آغازین یک کامپوننت مانند دریافت اطلاعات از سرور، استفاده میشود.
ب) OnChanges: از آن جهت انجام اعمالی پس از تغییرات input properties استفاده میشود.
خواص ورودی و همچنین کار با سرور را در قسمتهای بعدی بررسی خواهیم کرد.
ج) OnDestroy: از آن جهت پاکسازی منابع اختصاص داده شده استفاده میشود.
برای استفادهی از این hookها، نیاز است اینترفیس آنها را پیاده سازی کنیم. از آنجائیکه AngularJS 2.0 نیز با TypeScript نوشته شدهاست، به همراه تعدادی اینترفیس از پیش تعریف شده میباشد. برای مثال به ازای هر life cycle hook، یک اینترفیس تعریف شده در آن وجود دارد. برای نمونه اینترفیس hook ایی به نام OnInit، دقیقا همان OnInit، نام دارد (و با I شروع نشدهاست):
پس از ذکر implements OnInit در انتهای تعریف کلاس، اکنون باید ماژول مرتبط با آن نیز جهت شناسایی این اینترفیس import شود:
و دست آخر متد ngOnInit تعریف شدهی در این اینترفیس باید توسط کلاس پیاده سازی کنندهی آن تامین شود:
نام این متدها عموما شروع شده با ng و ختم شده به نام اینترفیس hook متناظر هستند؛ مانند ngOnInit فوق.
به عنوان تمرین، فایل product-list.component.ts را گشوده و سه مرحلهی implements سپس import و در آخر تعریف متد ngOnInit فوق را به آن اضافه کنید.
در ادامه برنامه را اجرا کرده و به کنسول developer tools مرورگر خود جهت مشاهدهی console.log فوق مراجعه کنید:
ساخت یک Pipe سفارشی جهت فعال سازی textbox فیلتر کردن محصولات
همانطور که در قسمت قبل نیز عنوان شد، کار pipes، تغییر اطلاعات حاصل از data binding، پیش از نمایش آنها در رابط کاربری است و AngularJS 2.0 به همراه تعدادی pipe توکار است؛ مانند currency، percent و غیره. در ادامه قصد داریم یک pipe سفارشی را ایجاد کنیم تا بر روی حلقهی ngFor* نمایش لیست محصولات تاثیرگذار شود و همچنین ورودی خود را از مقدار وارد شدهی توسط کاربر دریافت کند.
برای این منظور، یک فایل جدید را به نام product-filter.pipe.ts به پوشهی products اضافه کنید. سپس کدهای آنرا به نحو ذیل تغییر دهید:
برای تعریف یک pipe سفارشی جدید، کار با پیاده سازی اینترفیس PipeTransform شروع میشود. این اینترفیس دارای متدی است به نام transform که امضای آنرا در کدهای فوق ملاحظه میکنید. کار آن اعمال تغییرات بر روی value دریافتی و سپس بازگشت آن است. بنابراین اولین پارامتر آن، مقادیر اصلی را که قرار است تغییر کنند، مشخص میکند. در اینجا نوع آنرا از نوع اینترفیسی که در ابتدای بحث تعریف کردیم، تعیین کردهایم. پارامتر دوم آن، لیست پارامترها و آرگومانهای اختیاری این فیلتر را مشخص میکند.
برای مثال در اینجا میخواهیم شرایط فیلتر محصولات وارد شدهی توسط کاربر را دریافت کنیم.
خروجی این متد نیز از نوع آرایهای از IProduct تعریف شدهاست؛ از این جهت که نتیجه نهایی فیلتر اطلاعات نیز آرایهای از همین نوع است. کار این pipe پیاده سازی متد contains به صورت غیرحساس به کوچکی و بزرگی حروف است.
سپس بلافاصله بالای نام این کلاس، از یک decorator جدید به نام Pipe استفاده شدهاست تا به AngularJS 2.0 اعلام شود، این کلاس، صرفا یک کلاس معمولی نیست و یک Pipe است.
در ابتدای فایل هم importهای لازم جهت تعریف اینترفیسهای مورد استفادهی در این ماژول، ذکر شدهاند.
اگر دقت کنید، الگوی ایجاد یک pipe جدید، بسیار شبیه است به الگوی ایجاد یک کامپوننت و از این لحاظ سعی شدهاست طراحی یک دستی در سراسر این فریم ورک بکار گرفته شود.
پس از تعریف این pipe سفارشی، برای استفادهی از آن در یک template، به فایل product-list.component.html مراجعه کرده و سپس ngFor* آنرا به نحو ذیل تغییر میدهیم:
همانطور که ملاحظه میکنید، نام این pipe جدید که در decorator مرتبط با آن، توسط خاصیت name مشخص گردیدهاست، ذکر شدهاست. پس از آن یک : قرار گرفتهاست که مشخص کنندهی پارامتر اول این pipe است که در اینجا خاصیت listFilter تعریف شدهی در قسمت قبل را به آن انتساب دادهایم.
اگر از قسمت قبل به خاطر داشته باشید، این خاصیت را توسط two-way binding به روز میکنیم (اطلاعات وارد شدهی در textbox، بلافاصله به این خاصیت منعکس میشوند و برعکس):
تا اینجا این pipe را در قالب لیست محصولات بکار بردیم؛ اما کامپوننت آن نمیداند که این pipe را باید از کجا تامین کند. به همین جهت فایل product-list.component.ts را گشوده و خاصیت pipes را به نحو ذیل مقدار دهی کنید:
در اینجا دو کار صورت گرفتهاست. ابتدا افزودن pipe جدید ProductFilterPipe به لیست خاصیت pipes کامپوننت و سپس import ماژول آن درابتدای فایل.
اکنون اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
در اینجا چون مقدار فیلتر وارد شدهی پیش فرض، cart است، فقط ردیف Garden Cart نمایش داده شدهاست. اگر این مقدار را خالی کنیم، تمام ردیفها نمایش داده میشوند و اگر برای مثال ham را جستجو کنیم، فقط ردیف Hammer نمایش داده میشود.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MVC5Angular2.part5.zip
خلاصهی بحث
- اینترفیسها یکی از روشهای بهبود strong typing برنامههای AngularJS 2.0 هستند.
- جهت مدیریت بهتر شیوهنامههای هر کامپوننت بهتر است از روش styleUrls استفاده شود تا از نشتیهای تعاریف شیوهنامهها جلوگیری گردد.
- از life cycle hooks برای مدیریت رخدادهای مرتبط با طول عمر یک کامپوننت استفاده میشود؛ برای مثال دریافت اطلاعات از سرور و یا پاکسازی منابع مصرفی.
- تعریف یک pipe سفارشی با پیاده سازی اینترفیس PipeTransform انجام میشود. سپس نام این Pipe، به قالب مدنظر اضافه شده و در ادامه نیاز است کامپوننت استفاده کنندهی از این قالب را نیز از وجود این Pipe مطلع کرد.
افزودن strong typing به کامپوننت نمایش لیست محصولات
یکی از مزایای کار با TypeScript امکان انتساب نوعهای مشخص یا سفارشی، به متغیرها و اشیاء تعریف شدهاست. برای مثال تاکنون هر خاصیت تعریف شدهای دارای نوع است. اما هنوز نوعی را برای آرایهی محصولات تعریف نکردهایم و نوع آن، نوع پیش فرض any است که برخلاف رویهی متداول کار با TypeScript است.
برای تعریف نوعهای سفارشی میتوان از اینترفیسهای TypeScript استفاده کرد. یک اینترفیس، قراردادی است که نحوهی تعریف تعدادی خاصیت و متد به هم مرتبط را مشخص میکند. سپس کلاسهای مختلف میتوانند با پیاده سازی این اینترفیس، قرارداد تعریف شدهی در آن را عملی کنند. همچنین از اینترفیسها میتوان به عنوان یک data type جدید نیز استفاده کرد. البته ES 5 و ES 6 از اینترفیسها پشتیبانی نمیکنند و تعریف آنها در TypeScript صرفا جهت کمک به کامپایلر، برای یافتن خطاها، پیش از اجرای برنامه است و به کدهای جاوا اسکریپتی معادلی ترجمه نمیشوند.
در ادامه برای تکمیل مثال این سری، فایل جدید App\products\product.ts را به پروژه اضافه کنید؛ با این محتوا:
export interface IProduct { productId: number; productName: string; productCode: string; releaseDate: string; price: number; description: string; starRating: number; imageUrl: string; }
همچنین از آنجائیکه این اینترفیس را در یک فایل ts مجزا قرار دادهایم، برای اینکه بتوان از آن در سایر قسمتهای برنامه استفاده کرد، نیاز است در ابتدای آن، واژهی کلیدی export را نیز ذکر کرد.
پس از تعریف این اینترفیس، برای استفاده از آن به عنوان یک data type جدید، ابتدا ماژول آن import خواهد شد و سپس از نام آن به عنوان نوع دادهی جدیدی، استفاده میشود. برای این منظور فایل product-list.component.ts را گشوده و تغییرات ذیل را به آن اعمال کنید:
import { Component } from 'angular2/core'; import { IProduct } from './product'; @Component({ selector: 'pm-products', templateUrl: 'app/products/product-list.component.html' }) export class ProductListComponent { // as before ... products: IProduct[] = [ // as before ... ]; // as before ... }
مزیت اینکار این است که برای مثال در اینجا اگر در لیست اعضای آرایهی products، نام خاصیتی اشتباه تایپ شده باشد یا حتی بجای عدد، از رشته استفاده شده باشد، بلافاصله در ادیتور مورد استفاده، خطای مرتبط گوشزد شده و همچنین این فایل دیگر کامپایل نخواهد شد. به علاوه اینبار برای تعریف خواص اعضای آرایهی products، ادیتور مورد استفاده، intellisense را نیز دراختیار ما قرار میدهد و کاملا مشخص است که چه اعضایی مدنظر هستند و نوع آنها چیست.
مدیریت cssهای هر کامپوننت به صورت مجزا
هنگام ساخت یک قالب یا template، در بسیاری از اوقات نیاز است css مرتبط با آن نیز، منحصر به همان قالب بوده و نشتی نداشته باشد. برای مثال زمانیکه یک کامپوننت را درون کامپوننتی دیگر قرار میدهیم، باید css آن نیز در دسترس قرار بگیرد و css فعلی کامپوننت دربرگیرنده را بازنویسی نکند. روشهای مختلفی برای مدیریت این مساله وجود دارند:
الف) تعریف شیوه نامهها به صورت inline داخل خود قالبها. این حالت، مشکلات نگهداری و استفادهی مجدد را دارد.
ب) تعریف شیوه نامهها در یک فایل خارجی css و سپس لینک کردن آن به صفحهای اصلی یا index.html
در این حالت به ازای هر فایل، یکبار باید این تعریف در صفحهای اصلی سایت صورت گیرد. همچنین این فایلها میتوانند مقادیر یکدیگر را بازنویسی کرده و بر روی هم تاثیر بگذارند.
ج) تعریف شیوه نامهها به همراه تعریف کامپوننت. این روشی است که توسط AngularJS توصیه شدهاست و نگهداری و مقیاس پذیری آن سادهتر است.
تزئین کنندهی Component به همراه دو خاصیت دیگر به نامهای styles و stylesUrl نیز میباشد.
در حالت استفاده از خاصیت styles، شیوهنامهی متناظر با کامپوننت، در همانجا به صورت inline تعریف میشود:
@Component({ //... styles: ['thead {color: blue;}'] })
روش بهتر، استفاده از خاصیت styleUrls است که در آن میتوان مسیر یک یا چند فایل css را مشخص کرد:
@Component({ //... styleUrls: ['app/products/product-list.component.css'] })
برای آزمایش آن فایل جدید product-list.component.css را به پوشهی products مثال این سری اضافه کنید؛ با این محتوا:
thead { color: #337AB7; }
@Component({ selector: 'pm-products', templateUrl: 'app/products/product-list.component.html', styleUrls: ['app/products/product-list.component.css'] }) export class ProductListComponent { //...
یک نکته
شیوه نامهای که به این صورت توسط AngularJS 2.0 اضافه میشود، با سایر شیوه نامههای موجود تداخل نخواهد کرد. علت آنرا در تصویر ذیل که با استفاده از developer tools مرورگرها قابل بررسی است، میتوان مشاهده کرد:
در اینجا AngularJS 2.0، با ایجاد ویژگیهای سفارشی خودکار (attributes) میدان دید css را کنترل میکند. به این ترتیب شیوه نامهی کامپوننت یک، که درون کامپوننت دو قرار گرفتهاست، نشتی نداشته و بر روی سایر قسمتهای صفحه تاثیری نخواهد گذاشت؛ برخلاف شیوه نامههایی که به صورت متداولی به صفحهی اصلی سایت لینک شدهاند.
بررسی چرخهی حیات کامپوننتها
هر کامپوننت دارای چرخهی حیاتی است که توسط AngularJS 2.0 مدیریت میشود و شامل مراحلی مانند ایجاد، رندر، ایجاد و رندر فرزندان آن، پردازش تغییرات آن و در نهایت تخریب آن کامپوننت میشود. برای اینکه بتوان با برنامه نویسی به این مراحل چرخهی حیات یک کامپوننت دسترسی یافت، تعدادی life cycle hook طراحی شدهاند. سه مورد از مهمترین life cycle hooks شامل موارد ذیل هستند:
الف) OnInit: از این hook برای انجام کارهای آغازین یک کامپوننت مانند دریافت اطلاعات از سرور، استفاده میشود.
ب) OnChanges: از آن جهت انجام اعمالی پس از تغییرات input properties استفاده میشود.
خواص ورودی و همچنین کار با سرور را در قسمتهای بعدی بررسی خواهیم کرد.
ج) OnDestroy: از آن جهت پاکسازی منابع اختصاص داده شده استفاده میشود.
برای استفادهی از این hookها، نیاز است اینترفیس آنها را پیاده سازی کنیم. از آنجائیکه AngularJS 2.0 نیز با TypeScript نوشته شدهاست، به همراه تعدادی اینترفیس از پیش تعریف شده میباشد. برای مثال به ازای هر life cycle hook، یک اینترفیس تعریف شده در آن وجود دارد. برای نمونه اینترفیس hook ایی به نام OnInit، دقیقا همان OnInit، نام دارد (و با I شروع نشدهاست):
export class ProductListComponent implements OnInit {
import { Component, OnInit } from 'angular2/core';
ngOnInit(): void { console.log('In OnInit'); }
به عنوان تمرین، فایل product-list.component.ts را گشوده و سه مرحلهی implements سپس import و در آخر تعریف متد ngOnInit فوق را به آن اضافه کنید.
در ادامه برنامه را اجرا کرده و به کنسول developer tools مرورگر خود جهت مشاهدهی console.log فوق مراجعه کنید:
ساخت یک Pipe سفارشی جهت فعال سازی textbox فیلتر کردن محصولات
همانطور که در قسمت قبل نیز عنوان شد، کار pipes، تغییر اطلاعات حاصل از data binding، پیش از نمایش آنها در رابط کاربری است و AngularJS 2.0 به همراه تعدادی pipe توکار است؛ مانند currency، percent و غیره. در ادامه قصد داریم یک pipe سفارشی را ایجاد کنیم تا بر روی حلقهی ngFor* نمایش لیست محصولات تاثیرگذار شود و همچنین ورودی خود را از مقدار وارد شدهی توسط کاربر دریافت کند.
برای این منظور، یک فایل جدید را به نام product-filter.pipe.ts به پوشهی products اضافه کنید. سپس کدهای آنرا به نحو ذیل تغییر دهید:
import { PipeTransform, Pipe } from 'angular2/core'; import { IProduct } from './product'; @Pipe({ name: 'productFilter' }) export class ProductFilterPipe implements PipeTransform { transform(value: IProduct[], args: string[]): IProduct[] { let filter: string = args[0] ? args[0].toLocaleLowerCase() : null; return filter ? value.filter((product: IProduct) => product.productName.toLocaleLowerCase().indexOf(filter) != -1) : value; } }
برای مثال در اینجا میخواهیم شرایط فیلتر محصولات وارد شدهی توسط کاربر را دریافت کنیم.
خروجی این متد نیز از نوع آرایهای از IProduct تعریف شدهاست؛ از این جهت که نتیجه نهایی فیلتر اطلاعات نیز آرایهای از همین نوع است. کار این pipe پیاده سازی متد contains به صورت غیرحساس به کوچکی و بزرگی حروف است.
سپس بلافاصله بالای نام این کلاس، از یک decorator جدید به نام Pipe استفاده شدهاست تا به AngularJS 2.0 اعلام شود، این کلاس، صرفا یک کلاس معمولی نیست و یک Pipe است.
در ابتدای فایل هم importهای لازم جهت تعریف اینترفیسهای مورد استفادهی در این ماژول، ذکر شدهاند.
اگر دقت کنید، الگوی ایجاد یک pipe جدید، بسیار شبیه است به الگوی ایجاد یک کامپوننت و از این لحاظ سعی شدهاست طراحی یک دستی در سراسر این فریم ورک بکار گرفته شود.
پس از تعریف این pipe سفارشی، برای استفادهی از آن در یک template، به فایل product-list.component.html مراجعه کرده و سپس ngFor* آنرا به نحو ذیل تغییر میدهیم:
<tr *ngFor='#product of products | productFilter:listFilter'>
اگر از قسمت قبل به خاطر داشته باشید، این خاصیت را توسط two-way binding به روز میکنیم (اطلاعات وارد شدهی در textbox، بلافاصله به این خاصیت منعکس میشوند و برعکس):
<input type='text' [(ngModel)]='listFilter' />
import { Component, OnInit } from 'angular2/core'; import { IProduct } from './product'; import { ProductFilterPipe } from './product-filter.pipe'; @Component({ selector: 'pm-products', templateUrl: 'app/products/product-list.component.html', styleUrls: ['app/products/product-list.component.css'], pipes: [ProductFilterPipe] }) export class ProductListComponent implements OnInit { //...
اکنون اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
در اینجا چون مقدار فیلتر وارد شدهی پیش فرض، cart است، فقط ردیف Garden Cart نمایش داده شدهاست. اگر این مقدار را خالی کنیم، تمام ردیفها نمایش داده میشوند و اگر برای مثال ham را جستجو کنیم، فقط ردیف Hammer نمایش داده میشود.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MVC5Angular2.part5.zip
خلاصهی بحث
- اینترفیسها یکی از روشهای بهبود strong typing برنامههای AngularJS 2.0 هستند.
- جهت مدیریت بهتر شیوهنامههای هر کامپوننت بهتر است از روش styleUrls استفاده شود تا از نشتیهای تعاریف شیوهنامهها جلوگیری گردد.
- از life cycle hooks برای مدیریت رخدادهای مرتبط با طول عمر یک کامپوننت استفاده میشود؛ برای مثال دریافت اطلاعات از سرور و یا پاکسازی منابع مصرفی.
- تعریف یک pipe سفارشی با پیاده سازی اینترفیس PipeTransform انجام میشود. سپس نام این Pipe، به قالب مدنظر اضافه شده و در ادامه نیاز است کامپوننت استفاده کنندهی از این قالب را نیز از وجود این Pipe مطلع کرد.
در پروژه DNT Identity یک سرویس لاگر سفارشی بر همین مبنا تهیه شدهاست:
- سرویس لاگر سفارشی مبتنی بر EF Core
- کنترلر نمایش اطلاعات آن
- View مرتبط
- ثبت آن در سیستم: ^ و ^
- کنترلری که خطاهای سیستم را لاگ میکند و هدایت خطاها به این کنترلر
- سرویس لاگر سفارشی مبتنی بر EF Core
- کنترلر نمایش اطلاعات آن
- View مرتبط
- ثبت آن در سیستم: ^ و ^
- کنترلری که خطاهای سیستم را لاگ میکند و هدایت خطاها به این کنترلر
میشود متد SaveChanges را بر اساس مفاهیم Tracking سفارشی سازی کرد (مثال «ب» آن). در اینجا مثلا یک متد SaveChangesWithApplyYeKe جدید را درست کنید که این یکسان سازی را اعمال کند (مطابق مثال ب) و برای متد اصلی SaveChanges خیر. به این صورت میتوانید تصمیم گیری کنید که کجا این موارد اعمال شوند (با فراخوانی SaveChangesWithApplyYeKe سفارشی) یا خیر (با فراخوانی SaveChanges معمولی).