public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); services.AddResponseCompression(options => { options.Providers.Add<GzipCompressionProvider>(); options.EnableForHttps = true; }); } public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseResponseCompression(); } }
علت نیاز به Child Routes
در مثال این سری، منوی اصلی آن به صورت ذیل تعریف شدهاست:
<ul class="nav navbar-nav"> <li><a [routerLink]="['/home']">Home</a></li> <li><a [routerLink]="['/products']">Product List</a></li> <li><a [routerLink]="['/products', 0, 'edit']">Add Product</a></li> </ul>
<div class="container"> <router-outlet></router-outlet> </div>
کاربردهای Child routes
- امکان تقسیم فرمهای طولانی به چند Tab
- امکان طراحی طرحبندیهای Master/Layout
- قرار دادن قالب یک کامپوننت، درون قالب کامپوننتی دیگر
- بهبود کپسوله سازی ماژولهای برنامه
- جزو الزامات Lazy loading هستند
تنظیم کردن Child Routes
مثال جاری این سری، تنها به همراه یک سری primary routes است؛ مانند صفحهی خوشآمد گویی، نمایش لیست محصولات، افزودن و ویرایش محصولات. قالبهای کامپوننتهای اینها نیز در router-outlet اصلی برنامه نمایش داده میشوند. در ادامه میخواهیم کامپوننت ویرایش محصولات را تغییر داده و تعدادی برگه را به آن اضافه کنیم. برای اینکار، نیاز به تعریف Child routes است تا بتوان قالبهای کامپوننتهای هر برگه را در router-outlet کامپوننت والد که در درون router-outlet اصلی برنامه قرار دارد، نمایش داد.
به همین جهت دو کامپوننت جدید ProductEditInfo و ProductEditTags را نیز به ماژول محصولات اضافه میکنیم:
>ng g c product/ProductEditInfo >ng g c product/ProductEditTags
به علاوه اینترفیس src\app\product\iproduct.ts را نیز جهت افزودن گروه محصولات و همچنین آرایهی برچسبهای یک محصول تکمیل میکنیم:
export interface IProduct { id: number; productName: string; productCode: string; category: string; tags?: string[]; }
در ادامه برای تنظیم Child Routes، فایل src\app\product\product-routing.module.ts را گشوده و آنرا به نحو ذیل تکمیل کنید:
import { ProductEditTagsComponent } from './product-edit-tags/product-edit-tags.component'; import { ProductEditInfoComponent } from './product-edit-info/product-edit-info.component'; const routes: Routes = [ { path: 'products', component: ProductListComponent }, { path: 'products/:id', component: ProductDetailComponent, resolve: { product: ProductResolverService } }, { path: 'products/:id/edit', component: ProductEditComponent, resolve: { product: ProductResolverService }, children: [ { path: '', redirectTo: 'info', pathMatch: 'full' }, { path: 'info', component: ProductEditInfoComponent }, { path: 'tags', component: ProductEditTagsComponent } ] } ];
- در اولین Child Route تعریف شده، مقدار path به '' تنظیم شدهاست. به این ترتیب مسیریابی پیش فرض آن (در صورت عدم ذکر صریح آنها در URL) به صورت خودکار به مسیریابی info هدایت خواهد شد. بنابراین درخواست مسیر products/:id/edit به دومین Child Route تنظیم شده هدایت میشود.
- دومین Child Route تعریف شده با مسیری مانند products/:id/edit/info تطابق پیدا میکند.
- سومین Child Route تعریف شده با مسیری مانند products/:id/edit/tags تطابق پیدا میکند.
تعیین محل نمایش Child Views
برای نمایش قالب یک Child Route درون قالب والد آن، نیاز به تعریف یک دایرکتیو router-outlet جدید، درون قالب والد است و نحوهی تعریف آن با primary outlet تعریف شدهی در فایل src\app\app.component.html تفاوتی ندارد.
برای پیاده سازی این مفهوم، نیاز است از قالب ویرایش محصولات و یا فایل src\app\product\product-edit\product-edit.component.html که قالب والد این Child Routes است شروع و آنرا به دو Child View تقسیم کنیم. این قالب، تاکنون حاوی فرمی جهت ویرایش و افزودن محصولات است. در ادامه میخواهیم بجای آن چند برگه را نمایش دهیم. به همین جهت این فرم را حذف کرده و با دو برگهی جدید جایگزین میکنیم. در اینجا نحوهی تعریف لینکهای جدید، به Child Routes و همچنین محل قرارگیری router-outlet ثانویه را نیز مشاهده میکنید:
<div class="panel panel-primary"> <div class="panel-heading"> {{pageTitle}} </div> <div class="panel-body" *ngIf="product"> <div class="wizard"> <a [routerLink]="['info']"> Basic Information </a> <a [routerLink]="['tags']"> Search Tags </a> </div> <router-outlet></router-outlet> </div> <div class="panel-footer"> <div class="row"> <div class="col-md-6 col-md-offset-2"> <span> <button class="btn btn-primary" type="button" style="width:80px;margin-right:10px" [disabled]="!isValid()" (click)="saveProduct()"> Save </button> </span> <span> <a class="btn btn-default" [routerLink]="['/products']"> Cancel </a> </span> <span> <a class="btn btn-default" (click)="deleteProduct()"> Delete </a> </span> </div> </div> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </div>
فعالسازی Child Routes
دو روش برای فعالسازی Child Routes وجود دارند:
الف) با ذکر مسیر مطلق
<a [routerLink]="['/products',product.id,'edit','info']">Info</a>
ب) با ذکر مسیر نسبی
<a [routerLink]="['info']">Info</a>
در این حالت اگر تنظیمات والد این مسیریابی تغییر کنند، نیازی به تغییر مسیر نسبی تعریف شده نیست (برخلاف حالت مطلق که بر اساس قید کامل تمام اجزای مسیریابی والد آن کار میکند).
دقیقا همین پارامترها، قابلیت استفادهی در متد this.route.navigate را نیز دارند:
الف) برای حالت ذکر مسیر مطلق:
this.router.navigate(['/products', this.product.id,'edit','info']);
this.router.navigate(['info', { relativeTo: this.route }]);
تکمیل Child Viewهای برنامه
تا اینجا لینکهایی نسبی را به مسیریابیهای info و tags اضافه کردیم. در ادامه قالبها و کامپوننتهای آنها را تکمیل میکنیم:
الف) تکمیل کامپوننت ProductEditInfoComponent در فایل src\app\product\product-edit\product-edit.component.ts
import { ActivatedRoute } from '@angular/router'; import { NgForm } from '@angular/forms'; import { Component, OnInit, ViewChild } from '@angular/core'; import { IProduct } from './../iproduct'; @Component({ //selector: 'app-product-edit-info', templateUrl: './product-edit-info.component.html', styleUrls: ['./product-edit-info.component.css'] }) export class ProductEditInfoComponent implements OnInit { @ViewChild(NgForm) productForm: NgForm; errorMessage: string; product: IProduct; constructor(private route: ActivatedRoute) { } ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; if (this.productForm) { this.productForm.reset(); } }); } }
<div class="panel-body"> <form class="form-horizontal" novalidate #productForm="ngForm"> <fieldset> <legend>Basic Product Information</legend> <div class="form-group" [ngClass]="{'has-error': (productNameVar.touched || productNameVar.dirty || product.id !== 0) && !productNameVar.valid }"> <label class="col-md-2 control-label" for="productNameId">Product Name</label> <div class="col-md-8"> <input class="form-control" id="productNameId" type="text" placeholder="Name (required)" required minlength="3" [(ngModel)] = product.productName name="productName" #productNameVar="ngModel" /> <span class="help-block" *ngIf="(productNameVar.touched || productNameVar.dirty || product.id !== 0) && productNameVar.errors"> <span *ngIf="productNameVar.errors.required"> Product name is required. </span> <span *ngIf="productNameVar.errors.minlength"> Product name must be at least three characters. </span> </span> </div> </div> <div class="form-group" [ngClass]="{'has-error': (productCodeVar.touched || productCodeVar.dirty || product.id !== 0) && !productCodeVar.valid }"> <label class="col-md-2 control-label" for="productCodeId">Product Code</label> <div class="col-md-8"> <input class="form-control" id="productCodeId" type="text" placeholder="Code (required)" required [(ngModel)] = product.productCode name="productCode" #productCodeVar="ngModel" /> <span class="help-block" *ngIf="(productCodeVar.touched || productCodeVar.dirty || product.id !== 0) && productCodeVar.errors"> <span *ngIf="productCodeVar.errors.required"> Product code is required. </span> </span> </div> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </fieldset> </form> </div>
ب) تکمیل کامپوننت ProductEditTagsComponent در فایل src\app\product\product-edit-tags\product-edit-tags.component.ts
import { ActivatedRoute } from '@angular/router'; import { IProduct } from './../iproduct'; import { Component, OnInit } from '@angular/core'; @Component({ //selector: 'app-product-edit-tags', templateUrl: './product-edit-tags.component.html', styleUrls: ['./product-edit-tags.component.css'] }) export class ProductEditTagsComponent implements OnInit { errorMessage: string; newTags = ''; product: IProduct; constructor(private route: ActivatedRoute) { } ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; }); } // Add the defined tags addTags(): void { let tagArray = this.newTags.split(','); this.product.tags = this.product.tags ? this.product.tags.concat(tagArray) : tagArray; this.newTags = ''; } // Remove the tag from the array of tags. removeTag(idx: number): void { this.product.tags.splice(idx, 1); } }
<div class="panel-body"> <form class="form-horizontal" novalidate> <fieldset> <legend>Product Search Tags</legend> <div class="form-group" [ngClass]="{'has-error': (categoryVar.touched || categoryVar.dirty || product.id !== 0) && !categoryVar.valid }"> <label class="col-md-2 control-label" for="categoryId">Category</label> <div class="col-md-8"> <input class="form-control" id="categoryId" type="text" placeholder="Category (required)" required minlength="3" [(ngModel)]="product.category" name="category" #categoryVar="ngModel" /> <span class="help-block" *ngIf="(categoryVar.touched || categoryVar.dirty || product.id !== 0) && categoryVar.errors"> <span *ngIf="categoryVar.errors.required"> A category must be entered. </span> <span *ngIf="categoryVar.errors.minlength"> The category must be at least 3 characters in length. </span> </span> </div> </div> <div class="form-group" [ngClass]="{'has-error': (tagVar.touched || tagVar.dirty || product.id !== 0) && !tagVar.valid }"> <label class="col-md-2 control-label" for="tagsId">Search Tags</label> <div class="col-md-8"> <input class="form-control" id="tagsId" type="text" placeholder="Search keywords separated by commas" minlength="3" [(ngModel)]="newTags" name="tags" #tagVar="ngModel" /> <span class="help-block" *ngIf="(tagVar.touched || tagVar.dirty || product.id !== 0) && tagVar.errors"> <span *ngIf="tagVar.errors.minlength"> The search tag must be at least 3 characters in length. </span> </span> </div> <div class="col-md-1"> <button type="button" class="btn btn-default" (click)="addTags()"> Add </button> </div> </div> <div class="row col-md-8 col-md-offset-2"> <span *ngFor="let tag of product.tags; let i = index"> <button class="btn btn-default" style="font-size:smaller;margin-bottom:12px" (click)="removeTag(i)"> {{tag}} <span class="glyphicon glyphicon-remove"></span> </button> </span> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </fieldset> </form> </div>
دریافت اطلاعات جهت Child Routes
روشهای متعددی برای دریافت اطلاعات جهت Child Routes وجود دارند:
الف) میتوان از متد this.productService.getProduct جهت دریافت اطلاعات یک محصول استفاده کرد. اما همانطور که در قسمت قبل نیز بررسی کردیم، این روش سبب نمایش ابتدایی یک قالب خالی و پس از مدتی، نمایش اطلاعات آن میشود.
ب) میتوان توسط this.route.snapshot.data['product'] اطلاعات را از Route Resolver، پس از پیش واکشی آنها از وب سرور، دریافت کرد.
ج) اگر قسمتهای مختلف Child Routes قرار است با اطلاعاتی یکسان کار کنند که قرار است بین برگههای مختلف آن به اشتراک گذاشته شوند، این اطلاعات را میتوانند از Route Resolver والد خود به کمک this.route.snapshot.data['product'] دریافت کنند.
در این مثال ما هرچند چندین برگهی مختلف را طراحی کردهایم، اما اطلاعات نمایش داده شدهی توسط آنها متعلق به یک شیء محصول میباشند. بنابراین نیاز است بتوان این اطلاعات را بین کامپوننتهای مختلف این Child Routes به اشتراک گذاشت و تنها با یک وهلهی آن کار کرد. به همین جهت با this.route.parent در هر یک از Child Components تعریف شده کار میکنیم تا بتوان به یک وهلهی شیء محصول، دسترسی یافت.
د) همچنین میتوان از روش this.route.parent.data.subscribe نیز استفاده کرد. البته در اینجا چون صفحهی افزودن محصولات با صفحهی ویرایش محصولات، دارای root URL Segment یکسانی است، نیاز است از این روش استفاده کرد تا بتوان از تغییرات بعدی پارامتر id آن مطلع شد. این مورد روشی است که در کدهای ProductEditInfoComponent مشاهده میکنید.
ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; if (this.productForm) { this.productForm.reset(); } }); }
شبیه به همین روش را در ProductEditTagsComponent نیز بکار گرفتهایم و در آنجا نیز با شیء this.route.parent و دسترسی به اطلاعات دریافتی از Route Resolver، کار میکنیم. به این ترتیب مطمئن خواهیم شد که this.product این دو کامپوننت مختلف، هر دو به یک وهله از شیء product دریافتی از سرور، اشاره میکنند.
به این ترتیب دکمهی Save ذیل هر دو برگه، به درستی عمل کرده و میتواند اطلاعات نهایی یک شیء محصول را ذخیره کند.
رفع مشکلات اعتبارسنجی فرمهای قرار گرفتهی در برگههای مختلف
علت استفادهی از ViewChild در ProductEditInfoComponent
@ViewChild(NgForm) productForm: NgForm;
<form class="form-horizontal" novalidate #productForm="ngForm">
انجام اینکار برای برگههای دوم به بعد ضروری نیست. از این جهت که با اولین بار نمایش این صفحه، تمام آنها از حافظه خارج میشوند و مجددا بازیابی خواهند شد.
مشکل دوم اعتبارسنجی این فرم چند برگهای این است که هرچند خالی کردن نام یا کد محصول، سبب نمایش خطای اعتبارسنجی میشود، اما سبب غیرفعال شدن دکمهی Save نخواهند شد؛ از این جهت که این دکمه در قالب والد قرار دارد و نه در قالب فرزندان.
در اولین بار نمایش Child Routes، کامپوننت ویرایش اطلاعات در router-outlet آن نمایش داده میشود. در این حالت اگر کاربر بر روی لینک نمایش کامپوننت edit tags کلیک کند، قالب کامپوننت edit info به طور کامل از router-outlet حذف میشود و با قالب کامپوننت edit tags جایگزین میشود. این فرآیند به این معنا است که فرم edit info به همراه تمام اطلاعات اعتبارسنجی آن unload میشوند. به همین ترتیب زمانیکه کاربر درخواست نمایش برگهی ویرایش اطلاعات را میکند، قالب edit tags و اطلاعات اعتبارسنجی آن unload میشوند. به این معنا که در یک router-outlet در هر زمان تنها یک فرم، به همراه اطلاعات اعتبارسنجی آن در دسترس هستند.
راه حلهای ممکن:
الف) بدنهی اصلی فرم را در کامپوننت والد قرار دهیم و سپس هر کدام از فرزندان، المانهای فرمهای مرتبط را ارائه دهند. این روش کار نمیکند چون Angular المانهای فرمهای قرار گرفتهی درون router-outlet را شناسایی نمیکند.
ب) قرار دادن فرمها، به صورت مجزا در هر کامپوننت فرزند (مانند روش فعلی) و سپس اعتبارسنجی دستی در کامپوننت والد.
تغییرات مورد نیاز کامپوننت ProductEditComponent را جهت افزودن اعتبارسنجی فرمهای فرزند آنرا در اینجا ملاحظه میکنید:
export class ProductEditComponent implements OnInit { private dataIsValid: { [key: string]: boolean } = {}; isValid(path: string): boolean { this.validate(); if (path) { return this.dataIsValid[path]; } return (this.dataIsValid && Object.keys(this.dataIsValid).every(d => this.dataIsValid[d] === true)); } saveProduct(): void { if (this.isValid(null)) { this.productService.saveProduct(this.product) .subscribe( () => this.onSaveComplete(`${this.product.productName} was saved`), (error: any) => this.errorMessage = <any>error ); } else { this.errorMessage = 'Please correct the validation errors.'; } } validate(): void { // Clear the validation object this.dataIsValid = {}; // 'info' tab if (this.product.productName && this.product.productName.length >= 3 && this.product.productCode) { this.dataIsValid['info'] = true; } else { this.dataIsValid['info'] = false; } // 'tags' tab if (this.product.category && this.product.category.length >= 3) { this.dataIsValid['tags'] = true; } else { this.dataIsValid['tags'] = false; } } }
- سپس متد validate اضافه شدهاست تا کار اعتبارسنجی را انجام دهد. در اینجا از خود شیء this.product که بین دو برگه به اشتراک گذاشته شدهاست برای انجام اعتبارسنجی استفاده میکنیم. از این جهت که برگهها نیز با استفاده از this.route.parent.data، دقیقا به همین وهله دسترسی دارند. بنابراین هرتغییری که در برگهها بر روی این وهله اعمال شود، به کامپوننت والد نیز منعکس میشود.
- متد isValid، مسیر هر برگه را دریافت میکند و سپس به متغیر dataIsValid مراجعه کرده و وضعیت آن برگه را باز میگرداند. اگر path در اینجا قید نشود، وضعیت تمام برگهها بررسی میشوند؛ مانند if (this.isValid(null)) در متد ذخیره سازی اطلاعات.
- در آخر در فایل product-edit.component.html، وضعیت فعال و غیرفعال دکمهی ثبت را نیز به این متد متصل میکنیم:
<button class="btn btn-primary" type="button" style="width:80px;margin-right:10px" [disabled]="!isValid()" (click)="saveProduct()"> Save </button>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-routing-lab-04.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس از طریق خط فرمان به ریشهی پروژه وارد شده و دستور npm install را صادر کنید تا وابستگیهای آن دریافت و نصب شوند. در آخر با اجرای دستور ng s -o برنامه ساخته شده و در مرورگر پیش فرض سیستم نمایش داده خواهد شد.
پیشنیازهای کار با کش توزیع شدهی مبتنی بر SQL Server
برای کار با کش توزیع شدهی با قابلیت ذخیره سازی در یک بانک اطلاعاتی SQL Server، نیاز است دو بستهی ذیل را به فایل project.json برنامه اضافه کرد:
{ "dependencies": { "Microsoft.Extensions.Caching.SqlServer": "1.1.0" }, "tools": { "Microsoft.Extensions.Caching.SqlConfig.Tools": "1.1.0-preview4-final" } }
ایجاد جدول ذخیره سازی اطلاعات کش توزیع شده به کمک ابزار sql-cache
پس از افزودن و بازیابی ارجاعات فوق، با استفاده از خط فرمان، به پوشهی جاری برنامه وارد شده و دستور ذیل را صادر کنید:
dotnet sql-cache create "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=sql_cache;Integrated Security=True;" "dbo" "AppSqlCache"
- در اینجا میتوان هر نوع رشتهی اتصالی معتبری را به انواع و اقسام بانکهای SQL Server ذکر کرد. برای نمونه در مثال فوق این رشتهی اتصالی به یک بانک اطلاعاتی از پیش ایجاد شدهی LocalDB اشاره میکند. نام دلخواه این بانک اطلاعاتی در اینجا sql_cache ذکر گردیده و نام دلخواه جدولی که قرار است این اطلاعات را ثبت کند AppSqlCache تنظیم شدهاست و dbo، نام اسکیمای جدول است:
در اینجا تصویر ساختار جدولی را که توسط ابزار dotnet sql-cache ایجاد شدهاست، مشاهده میکنید. اگر خواستید این جدول را خودتان دستی ایجاد کنید، یک چنین کوئری را باید بر روی دیتابیس مدنظرتان اجرا نمائید:
CREATE TABLE AppSqlCache ( Id NVARCHAR (449) COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL, Value VARBINARY (MAX) NOT NULL, ExpiresAtTime DATETIMEOFFSET NOT NULL, SlidingExpirationInSeconds BIGINT NULL, AbsoluteExpiration DATETIMEOFFSET NULL, CONSTRAINT pk_Id PRIMARY KEY (Id) ); CREATE NONCLUSTERED INDEX Index_ExpiresAtTime ON AppSqlCache(ExpiresAtTime);
ایجاد جدول ذخیره سازی اطلاعات کش توزیع شده به کمک ابزار Migrations در EF Core
زیر ساخت کش توزیع شدهی مبتنی بر SQL Server هیچگونه وابستگی به EF Core ندارد و تمام اجزای آن توسط Async ADO.NET نوشته شدهاند. اما اگر خواستید قسمت ایجاد جدول مورد نیاز آنرا به ابزار Migrations در EF Core واگذار کنید، روش کار به صورت زیر است:
- ابتدا یک کلاس دلخواه جدید را با محتوای ذیل ایجاد کنید:
public class AppSqlCache { public string Id { get; set; } public byte[] Value { get; set; } public DateTimeOffset ExpiresAtTime { get; set; } public long? SlidingExpirationInSeconds { get; set; } public DateTimeOffset? AbsoluteExpiration { get; set; } }
public class MyDBDataContext : DbContext { public virtual DbSet<AppSqlCache> AppSqlCache { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<AppSqlCache>(entity => { entity.ToTable(name: "AppSqlCache", schema: "dbo"); entity.HasIndex(e => e.ExpiresAtTime).HasName("Index_ExpiresAtTime"); entity.Property(e => e.Id).HasMaxLength(449); entity.Property(e => e.Value).IsRequired(); }); } }
البته این مورد به شرطی است که بخواهید از یک دیتابیس، هم برای برنامه و هم برای ذخیره سازی اطلاعات کش استفاده کنید.
معرفی تنظیمات رشتهی اتصالی و نام جدول ذخیره سازی اطلاعات کش به برنامه
پس از ایجاد جدول مورد نیاز جهت ذخیره سازی اطلاعات کش، اکنون نیاز است این اطلاعات را به برنامه معرفی کرد. برای این منظور به کلاس آغازین برنامه مراجعه کرده و متد الحاقی AddDistributedSqlServerCache را بر روی مجموعهی سرویسهای موجود فراخوانی کنید؛ تا سرویسهای این کش توزیع شده نیز به برنامه معرفی شوند:
public void ConfigureServices(IServiceCollection services) { services.AddDistributedSqlServerCache(options => { options.ConnectionString = @"Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=sql_cache;Integrated Security=True;"; options.SchemaName = "dbo"; options.TableName = "AppSqlCache"; });
آزمایش کش توزیع شدهی تنظیمی با فعال سازی سشنها
سشنها را همانند نکات ذکر شدهی در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 16 - کار با Sessions» فعال کنید و سپس مقداری را در آن بنویسید:
public IActionResult Index() { HttpContext.Session.SetString("User", "VahidN"); return Json(true); } public IActionResult About() { var userContent = HttpContext.Session.GetString("User"); return Json(userContent); }
همانطور که مشاهده میکنید، سیستم سشن اینبار بجای حافظه، به صورت خودکار از جدول بانک اطلاعاتی SQL Server تنظیم شده، برای ذخیره سازی اطلاعات خود استفاده کردهاست.
کار با کش توزیع شده از طریق برنامه نویسی
همانطور که در مقدمهی بحث نیز عنوان شد، استفادهی از زیر ساخت کش توزیع شده منحصر به استفادهی از آن جهت ذخیره سازی اطلاعات سشنها نیست و از آن میتوان جهت انواع و اقسام سناریوهای مختلف مورد نیاز استفاده کرد. در این حالت روش دسترسی به این زیر ساخت، از طریق اینترفیس IDistributedCache است. زمانیکه متد AddDistributedSqlServerCache را فراخوانی میکنیم، در حقیقت کار ثبت یک چنین سرویسی به صورت خودکار انجام خواهد شد:
services.Add(ServiceDescriptor.Singleton<IDistributedCache, SqlServerCache>());
در اینجا یک نمونه از این تزریق وابستگی و سپس استفادهی از متدهای Set و Get اینترفیس IDistributedCache را مشاهده میکنید:
using System; using System.Text; using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Caching.Distributed; namespace Core1RtmEmptyTest.Controllers { public class CacheTestController : Controller { readonly IDistributedCache _cache; public CacheTestController(IDistributedCache cache) { _cache = cache; } public IActionResult SetCacheData() { var time = DateTime.Now.ToLocalTime().ToString(); var cacheOptions = new DistributedCacheEntryOptions { AbsoluteExpiration = DateTime.Now.AddYears(1) }; _cache.Set("Time", Encoding.UTF8.GetBytes(time), cacheOptions); return View(); } public IActionResult GetCacheData() { var time = Encoding.UTF8.GetString(_cache.Get("Time")); ViewBag.data = time; return View(); } public bool RemoveCacheData() { _cache.Remove("Time"); return true; } } }
Value VARBINARY (MAX) NOT NULL,
public byte[] Value { get; set; }
در این حالت اگر برنامه را اجرا و مسیر http://localhost:7742/CacheTest/SetCacheData را فراخوانی کنیم، اطلاعات ذخیره شدهی با کلید Test را میتوان در بانک اطلاعاتی مشاهده کرد:
Tag helper مخصوص کش توزیع شده
در ASP.NET Core، میتوان از یک Tag Helper جدید به نام distributed-cache برای کش سمت سرور توزیع شدهی محتوای قسمتی از یک View به نحو ذیل استفاده کرد:
<distributed-cache name="MyCacheItem2" expires-sliding="TimeSpan.FromMinutes(30)"> <p>From distributed-cache</p> @DateTime.Now.ToString() </distributed-cache>
در اینجا name به صورت هش شده به صورت کلید کش مورد استفاده قرار میگیرد. سپس محتوای تگ distributed-cache رندر شده، تبدیل به آرایهای از بایتها گردیده و در بانک اطلاعاتی ذخیره میگردد.
ذکر name در اینجا اجباری است و باید دقت داشت که چون به عنوان کلید بازیابی کش مورد استفاده قرار خواهد گرفت، نباید به اشتباه در قسمتهای دیگر برنامه با همین نام وارد شود. در غیر اینصورت دو قسمتی که name یکسانی داشته باشند، یک محتوا را نمایش خواهند داد.
EF Code First #12
در global.asax.cs دارید:
protected void Application_BeginRequest
public void Init(HttpApplication context) { context.BeginRequest += beginRequest; }
EF Code First #11
اما در مورد UoW خوب باز هم طبق تجربه حتی با وجود DbContext (و Session در NH) فکر میکنم وجودش خیلی مفیده. مثلا تو برنامه های وب UoWم رو برپایه HttpModule قرار میدم و موقع Dispose شدن ماژول، تغییرات رو ذخیره میکنم.
در مورد M در MVC کاملا با آقای نصیری موافقم. این بحثو مدتی پیش با یه دوستی هم داشتیم که زیر بار نرفت. مثالی که اونجا زدم اینجا میزارم، فکر کنم مفیده.
فکر کنید شیئی به نام Member دارید با مثلا 20 پراپرتی. و این 20 خاصیت، در 5 ویوی مختلف نمایش داده میشن. یعنی یه ویو 6 تا، یه ویو 3 تا و همینطور تا آخر. خوب عاقلانه نیست که وقتی که به هر 20 خاصیت نیاز نداریم، همشو واکشی کنیم. پس دو تا راه داریم. یا باید اون 3 4 تا خاصیتی که نیاز داریم رو جداگانه (مثلا تو یه Tuple یا Anon یا حتی متغیرهای منحصر) واکشی کنیم و در اختیار ویو بذاریم؛ یا بیایم و یه ساختمون (class یا struct) تعریف کنیم مخصوص اون 3 4 تا پراپرتی. خوب من روش دوم رو ترجیح میدم که همون view-model های منو میسازه. یا نمایی رو در نظر بگیرید که لازمه از ترکیبی از دو یا چند مدل داده استفاده کنه. تو همون مثال Member، فرض کنید نمایی هست که نام کاربری و نام و نام خانوادگی رو از Member و تعداد ارسال ها رو از Comments و آخرین فعالیت رو از MemberActivitis و آدرس ایمیل عمومی رو از AuthTokens میخونه! چه میکنید؟
ضمنا به فلسفه وجودی مثلا AutoMapper هم فکر کنیم.
الف) در متدهای لایه جاری خود واژههای کلیدی new و همچنین کلیه فراخوانیهای استاتیک را بیابید.
ب) وهله سازی اینها را به یک سطح بالاتر (نقطه آغازین برنامه) منتقل کنید. اینکار باید بر اساس اتکای به Abstraction و برای مثال استفاده از اینترفیسها صورت گیرد.
ج) اینکار را آنقدر تکرار کنید تا دیگر در کدهای لایه جاری خود واژه کلیدی new یا فراخوانی متدهای استاتیک مشاهده نشود.
د) در آخر وهله سازی object graphهای مورد نیاز را به یک IoC Container محول کنید.
یک مثال: ابتدا بررسی یک قطعه کد متداول
using System.Net; using System.Text; using System.Text.RegularExpressions; using System.Web.Mvc; namespace DI06.Controllers { public class HomeController : Controller { public ActionResult Index() { string result = string.Empty; using (var client = new WebClient { Encoding = Encoding.UTF8 }) { result = client.DownloadString("https://www.dntips.ir/"); } var match = new Regex(@"(?s)<title>(.+?)</title>", RegexOptions.IgnoreCase).Match(result); var title = match.Groups[1].Value.Trim(); ViewBag.PageTitle = title; return View(); } } }
مشکلات کد فوق:
الف) قرار گرفتن منطق تجاری پیاده سازی کدها مستقیما داخل کدهای یک اکشن متد؛ این مساله در دراز مدت به تکرار شدید کدها منجر خواهد شد که نهایتا قابلیت نگهداری آنرا کاهش میدهند.
ب) در این کد حداقل دو بار واژه کلیدی new ذکر شده است. مورد اول یا new WebClient، از همه مهمتر است؛ از این جهت که نوشتن آزمون واحد را برای این کنترلر بسیار مشکل میکند. آزمونهای واحد باید سریع و بدون نیاز به منابع خارجی، قابل اجرا باشند. تعویض آن هم مطابق کدهای تدارک دیده شده کار سادهای نیست.
بهبود کیفیت قطعه کد متداول فوق با استفاده از الگوی معکوس سازی وابستگیها
در اصل معکوس سازی وابستگیها عنوان کردیم لایه بالایی سیستم نباید مستقیما به لایههای زیرین در حال استفاده از آن، وابسته باشد. این وابستگی باید معکوس شده و همچنین بر اساس Abstraction یا برای مثال استفاده از اینترفیسها صورت گیرد.
به همین منظور یک پروژه دیگر را از نوع Class library، مثلا به نام DI06.Services به Solution جاری اضافه میکنیم.
namespace DI06.Services { public interface IWebClientServices { string FetchUrl(string url); string GetWebPageTitle(string url); } } using System.Net; using System.Text; using System.Text.RegularExpressions; namespace DI06.Services { public class WebClientServices : IWebClientServices { public string FetchUrl(string url) { using (var client = new WebClient { Encoding = Encoding.UTF8 }) { return client.DownloadString(url); } } public string GetWebPageTitle(string url) { var html = FetchUrl(url); var match = new Regex(@"(?s)<title>(.+?)</title>", RegexOptions.IgnoreCase).Match(html); return match.Groups[1].Value.Trim(); } } }
هنوز کار معکوس سازی وابستگیها رخ نداده است. صرفا اندکی تمیزکاری و انتقال پیاده سازی منطق تجاری به یک سری کلاسهایی با قابلیت استفاده مجدد صورت گرفته است. به این ترتیب اگر باگی در این کدها وجود داشته باشد و همچنین از آن در چندین نقطه برنامه استفاده شده باشد، اصلاح این کلاس مرکزی، به یکباره تمامی قسمتهای مختلف برنامه را تحت تاثیر مثبت قرار داده و از تکرار کدها و فراموشی احتمالی بهبود قسمتهای مشابه جلوگیری میکند.
کار معکوس سازی وابستگیها در یک لایه بالاتر صورت خواهد گرفت:
using System.Web.Mvc; using DI06.Services; namespace DI06.Controllers { public class HomeController : Controller { readonly IWebClientServices _webClientServices; public HomeController(IWebClientServices webClientServices) { _webClientServices = webClientServices; } public ActionResult Index() { ViewBag.PageTitle = _webClientServices.GetWebPageTitle("https://www.dntips.ir/"); return View(); } } }
در مورد نحوه تنظیمات اولیه یک IoC Container و یا پیشنیازهای ASP.NET MVC جهت آماده شدن برای تزریق خودکار وابستگیها در سازنده کنترلرها، پیشتر مطالبی را در این سری مطالعه کردهاید؛ در اینجا نیز اصول مورد استفاده یکی است و تفاوتی نمیکند.
زمانیکه تصمیم میگیریم کدهای زده شده را بهینه کنیم، اکثرا دنبال راه حلهای جدید نمیگردیم. این مورد کاملا غریزی است؛ چرا که بهدنبال کمترین انرژی و بیشترین بازدهی هستیم؛ این طبیعت انسان است. صرفا کدهای قبلی را بازبینی میکنیم و سعی میکنیم نحوهی نوشتن منطقهای موجود را بهینه کنیم. در همین راستا درک عملکرد Task و ValueTask ها شاید قدمی مهم در مورد بهینه کردن کدها باشد؛ چرا استفاده درست و بجای این دو مورد میتواند تاثیر زیادی بر روی سرعت و استفاده از مصرف حافظه داشته باشد؟ در این مقاله سعی میکنیم تا درک درستی از این دو داشته باشیم.
Task<T> چیست؟
Task یک کلاس در فضای نام System.Threading.Tasks است؛ بهطوریکه کمک میکند تا یک قسمت از برنامه به صورت مستقل از Thread اصلی اجرا شود. بهبیان دیگر میتواند یک Thread Pool را ایجاد و با توجه به روند کار، از یک مرحلهی اجرایی به مرحلهای دیگر منتقل میکند. همچنین هر Task میتواند یک مقدار برگشتی نیز داشته باشد.
این درحالیاست که میتواند صرفا یک فرآیند را اجرا کند، بدون اینکه خروجی داشته باشد. بهعبارتی دیگر اگر فرآیندی داشته باشیم که در نهایت یک شناسه را برمیگرداند، از Task<int> و اگر فرآیندی داشته باشیم که صرفا فرآیند همگام سازی دادههای قدیمی به جدید را انجام میدهد، میتواند از نوع Task باشد.
همانطور که اشاره شد، Task یک کلاس است که شامل متدها و فیلدهای مختلفی میباشد. با استفاده از این اعضا میتوان نحوهی اجرای کدها و وضعیتهای مختلف اجرای آن را مدیریت کرد، تا در نهایت اجرای آن کامل شود.
به دلیل اینکه Task یک class است و class ها از نوع ReferenceType میباشند، روی حافظهی Heap ذخیره میشوند و بهازای هر بار فراخوانی متدی که خروجی Task دارد، شیء Task را روی Heap ذخیره میکند. این شیء وضعیت اجرای قسمتی از کد ما را که میتواند sync یا async باشد، در خود ذخیره میکند تا در نهایت اجرای آن کامل شود.
نحوه استفاده از Task<T>
برای درک بهتر، یک تکه کد را با بهره بردن از Task ایجاد میکنیم :
public static class DummyWeatherProvider { public static async Task<Weather> Get(string city) { await Task.Delay(10); var weather = new Weather { City = city, Date = DateTime.Now, AvgTempratureF = new Random().Next(5, 70) }; return weather; } }
static async Task CheckTaskStatus() { var task = DummyWeatherProvider.Get("Stockholm"); LogTaskStatus(task.Status); await task; LogTaskStatus(task.Status); } static void LogTaskStatus(TaskStatus status) { Console.WriteLine($"Task Status: {Enum.GetName(typeof(TaskStatus), status)}"); }
ValueTask<T> چیست؟
همانند Task ، ValueTask هم برای مدیریت وضعیت فرآیند استفاده میشود؛ با این تفاوت که ValueTask ها از نوع struct هستند. بهطوریکه نحوهی ذخیره سازی آنها در حافظه به نسبت class ها کاملا متفاوت است. از نقطه نظر سرعت، تشخیص دادن اینکه کدامیک باید استفاده شود، باید با توجه به سناریو، بررسی و انتخاب شود؛ چرا که از نظر تخصیص حافظه متفاوت عمل میکنند. برای درک بهتر عملکرد ValueTask ها کد زیر را بررسی میکنیم :
public class WeatherService { private readonly ConcurrentDictionary<string, Weather> _cache; public WeatherService() { _cache = new(); } public async Task<Weather> GetWeatherTask(string city) { if (!_cache.ContainsKey(city)) { var weather = await DummyWeatherProvider.Get(city); _cache.TryAdd(city, weather); } return _cache[city]; } public async ValueTask<Weather> GetWeatherValueTask(string city) { if (!_cache.ContainsKey(city)) { var weather = await DummyWeatherProvider.Get(city); _cache.TryAdd(city, weather); } return _cache[city]; }
کلاس WeatherService شامل یک فیلد private از نوع collection و دو متد است. ما از _cache جهت نگهداری اطلاعاتی که قبلا دریافت شده، استفاده میکنیم و به نوعی in-memory cache را پیاده سازی میکنیم. پیاده سازی منطق هر دو متد GetWeatherTask و GetWeatherValueTask کاملا شبیه به هم است؛ بهطوریکه اول بررسی میکنیم اطلاعات آب و هوای شهر مورد نظر در _cache وجود دارد یا خیر؟ اگر وجود داشت، اطلاعات به صورت مستقیم برگشت داده میشود؛ در غیر این صورت DummyWeatherProvider.Get() فراخوانی خواهد شد.
در قدم بعدی اطلاعات بهدست آمده را در _cache ذخیره میکنیم. سپس مقدار ذخیره شده را برگشت میدهیم. در واقع تنها تفاوت دو متد ذکر شده، نوع خروجی آن میباشد؛ یکی از Taskو دیگری از ValueTask استفاده میکند.
برای مقایسهی مصرف حافظهی این دو روی هر دو متد، Benchmark میگیریم. برای پیاده سازی نیار به کدهای زیر داریم :
[MemoryDiagnoser] public class TaskAndValueTaskBenchmark { private readonly WeatherService _weatherService; public TaskAndValueTaskBenchmark() { _weatherService = new(); } [Benchmark] [Arguments("Denver")] public async Task<Weather> TaskBenchmark(string city) { return await _weatherService.GetWeatherTask(city); } [Benchmark] [Arguments("London")] public async ValueTask<Weather> ValueTaskBenchmark(string city) { return await _weatherService.GetWeatherValueTask(city); } }
نتیجه به دست آمده به شرح زیر است :
Allocated | Gen0 | Method |
144 B | 0.0229 | TaskBenchmark |
------ | ---- | ValueTaskBenchmark |
مزیت ValueTask<T>
بهدلیل اینکه از نوع struct هستند، بر روی حافظه، در قسمت Stack ذخیره میشوند و به صورت خودکار بعد از اینکه نیازی به آنها نباشد، از حافظه حذف میشوند . به همین دلیل به شکل قابل توجهی، فشار را از روی GC کاهش میدهد .
علاوه بر این، در سناریویی که اکثر کدها به صورت sync اجرا میشوند، در این مواقع استفاده از ValueTask، بهتر از Task میباشد .
این سری متد GetWeatherValueTask
را جهت تشخص اینکه اغلب کدها به صورت sync یا async اجرا میشوند، بررسی میکنیم. در
متد ذکر شده اگر اطلاعات شهر مورد نظر وجود داشته باشد، کار به صورت sync اجرا میشود و اگر شهر وجود
نداشته باشد، کار به صورت async اجرا میشود. با بررسی دقیقتر متوجه میشویم اکثر مواقع در این متد کار به صورت sync
اجرا میشود؛ چرا که بعد ازدریافت
اطلاعات، مجدد آن را دریافت نمیکند، بلکه از حافظه میخواند (همان _cache ) .
محدودیتهای استفاده از ValueTask<T>
1. در اینجا تنها یکبار امکان استفاده از await وجود دارد. وقتی یکبار valueTask را await میکنیم، بهتر است کار دیگری بر روی آن انجام ندهیم؛ چراکه ممکن است از حافظه پاک شده باشد.
2. اگر در سناریویی لازم دارید چندین بار await را بر روی valueTask اجرا کنید، لازم است ابتدا آن را به Task تبدیل کنیم. برای این کار متد AsTask را فراخوانی میکنیم (بهتر است صرفا یکبار متد AsTask را فراخوانی کنیم).
3. نمیتوانیم به یک ValueTask به صورت هم زمان در حالت Multi threads دسترسی داشته باشیم.
4. به صورت پیش فرض خروجی عملیات async، نوع Task میباشد؛ مگر اینکه اغلب مراحل کار به صورت sync اجرا شود، مانند مثالی که بالاتر اشاره شد.
منابع :
آیا به این نتیجه رسیدید که اصل DRY را نقض کردهایم؟ بله همین طور است. تکرار کلاسهای css مربوط به بوت استرپ، تکرار هلپرهای توکار ASP.NET MVC بارها و بارها، خوانایی کد را پایین میارود و در برخی موارد هم خسته کننده خواهد بود. اگر با مباحث مربوط به EditorTemplateها قبلا آشنا شده باشید، خیلی سریع عنوان خواهید کرد که بهتر است از این امکان بهره برد؛ بله درست است. برای این منظور در مسیر Views/Shared/EditorTemplates، فایل cshtml. همنام با نوع داده مد نظر را ایجاد میکنیم.
String.cshtml
@model string @Html.TextBox("",ViewData.TemplateInfo.FormattedModelValue, new { @class="form-control",placeholder=ViewData.ModelMetadata.Watermark})
Enum.cshtml
@model Enum @Html.EnumDropDownListFor(m => Model, new { @class = "form-control" })
حال دوباره به نتیجه حاصل از تغییرات اعمال شده توجه کنید:
این نتیجه امیدوار کننده است ولی بازهم یکسری از کدها بی دلیل تکرار شدهاند. هلپرهای زیر نیز میتوانند در کاهش کدها به کمک ما برسند :
public static class BootstrapHelpers { public static IHtmlString BootstrapLabelFor<TModel,TProp>( this HtmlHelper<TModel> helper, Expression<Func<TModel,TProp>> property) { return helper.LabelFor(property, new { @class = "col-md-2 control-label" }); } public static IHtmlString BootstrapLabel( this HtmlHelper helper, string propertyName) { return helper.Label(propertyName, new { @class = "col-md-2 control-label" }); } }
از کلاس بالا برای عدم تکرار کلاسهای بوت استرپ مربوط به Label، استفاده میشود .
حال دوباره نتیجه را مشاهده کنید:
خیلی عالی؛ توانستیم از تکرار یکسری از کلاسهای بوت استرپ خلاص شویم. اما در ادامه با استفاده از یک Object Template به عنوان EditorTemplate برای نوع دادههای Complex، کار را تمام خواهیم کرد.
EditorTemplateهای تعریف شده در بالا، صرفا برای نوع دادههای خاصی مورد استفاده قرار خواهند گرفت؛ ولی پیاده سازی یک EditorTemplate جنریک که حتی از ویومدلهای موجود در پروژه نیز پشتیابی کند، به شکل زیر خواهد بود.
Object.cshtml
@model dynamic @foreach (var prop in ViewData.ModelMetadata.Properties .Where(p => p.ShowForEdit)) { if (prop.TemplateHint == "HiddenInput") { @Html.Hidden(prop.PropertyName) } else { <div class="form-group"> @Html.BootstrapLabel(prop.PropertyName) <div class="col-md-10"> @Html.Editor(prop.PropertyName) @Html.ValidationMessage(prop.PropertyName) </div> </div> } }
با استفاده از ViewData.ModelMetadata میتوان به خصوصیات مدل مربوط به ویو دسترسی پیدا کرد که در بالا با استفاده از همین خصوصیت به تمام پراپرتیهای مدل دسترسی پیدا کرده و مقداری کد تکراری باقی مانده را هم در اینجا کپسوله کردیم.
حال کافی است به شکل زیر عمل کنیم:
در مورد نحوهی نمایش شماره صفحه جاری در مثلا header یک گزارش PDF تهیه شده به کمک writer.PageNumber و ارث بری از کلاس PdfPageEventHelper، در پایان مطلب فارسی نویسی در iTextSharp توضیح داده شد. این مورد جزو ضروریات یک گزارش خوب است، اما عموما نیاز است تا تعداد کل صفحات هم نمایش داده شود. مثلا صفحه n از 100 جایی در تمام صفحات درج شود و ... هیچ خاصیتی به نام TotalNumberOfPages را در این کتابخانه نمیتوان یافت. علت هم این است که تعداد واقعی کل صفحات فقط در حین بسته شدن شیء Document مشخص میشود و نه در هنگام تهیه صفحات. بنابراین نکته تهیه و نمایش تعداد صفحات، در iTextSharp به صورت خلاصه به شرح زیر است:
الف) باید در همان کلاسی که از PdfPageEventHelper به ارث رسیده است، متد OnCloseDocument را تحریف (override) کرد. در اینجا به خاصیت writer.PageNumber دسترسی داریم و writer.PageNumber - 1 مساوی است با تعداد کل صفحات.
ب) در مرحله بعد نیاز است تا این عدد را به نحوی به تمام صفحات تولید شده اضافه کنیم. این کار هم ساده است و مبتنی است بر بکارگیری یک PdfTemplate :
- در متد تحریف شدهی OnOpenDocument ، یک قالب PDF ساده را تولید میکنیم (مثلا یک مستطیل کوچک خالی).
- سپس در متد OnEndPage ، این قالب را به انتهای تمام صفحات در حال تولید اضافه خواهیم کرد.
- زمانیکه متد OnCloseDocument فراخوانده شد، عدد تعداد کل صفحات را در این قالب که به تمام صفحات اضافه شده، درج خواهیم کرد. به این ترتیب این عدد به صورت خودکار در تمام صفحات نمایش داده خواهد شد.
پیاده سازی این توضیحات را در ادامه ملاحظه خواهید کرد:
using System;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;
namespace iTextSharpTests
{
public class PdfWriterPageEvents : PdfPageEventHelper
{
PdfContentByte _pdfContentByte;
// عدد نهایی تعداد کل صفحات را در این قالب قرار خواهیم داد
PdfTemplate _template;
BaseFont _baseFont;
public override void OnOpenDocument(PdfWriter writer, Document document)
{
_baseFont = BaseFont.CreateFont(BaseFont.HELVETICA, BaseFont.CP1252, BaseFont.NOT_EMBEDDED);
_pdfContentByte = writer.DirectContent;
_template = _pdfContentByte.CreateTemplate(50, 50);
}
public override void OnEndPage(PdfWriter writer, Document document)
{
base.OnEndPage(writer, document);
String text = writer.PageNumber + "/";
float len = _baseFont.GetWidthPoint(text, 8);
Rectangle pageSize = document.PageSize;
_pdfContentByte.SetRGBColorFill(100, 100, 100);
_pdfContentByte.BeginText();
_pdfContentByte.SetFontAndSize(_baseFont, 8);
_pdfContentByte.SetTextMatrix(pageSize.GetLeft(40), pageSize.GetBottom(30));
_pdfContentByte.ShowText(text);
_pdfContentByte.EndText();
//در پایان هر صفحه یک جای خالی را مخصوص تعداد کل صفحات رزرو خواهیم کرد
_pdfContentByte.AddTemplate(_template, pageSize.GetLeft(40) + len, pageSize.GetBottom(30));
}
public override void OnCloseDocument(PdfWriter writer, Document document)
{
base.OnCloseDocument(writer, document);
_template.BeginText();
_template.SetFontAndSize(_baseFont, 8);
_template.SetTextMatrix(0, 0);
//درج تعداد کل صفحات در تمام قالبهای اضافه شده
_template.ShowText((writer.PageNumber - 1).ToString());
_template.EndText();
}
}
public class AddTotalNoPages
{
public static void CreateTestPdf()
{
using (var pdfDoc = new Document(PageSize.A4))
{
var pdfWriter = PdfWriter.GetInstance(pdfDoc, new FileStream("tpn.pdf", FileMode.Create));
pdfWriter.PageEvent = new PdfWriterPageEvents();
pdfDoc.Open();
pdfDoc.Add(new Phrase("Page1"));
pdfDoc.NewPage();
pdfDoc.Add(new Phrase("Page2"));
pdfDoc.NewPage();
pdfDoc.Add(new Phrase("Page3"));
}
}
}
}
کار این کلاس در واقع ترکیب کلاسها و کتابخانههای کاری مشخص است که نیاز به ارتباط با یکدیگر را دارند. به عنوان مثال یک برنامه کتابخانه، برای وظیفهای چون امانت یک کتاب نیاز است تا چندین کلاس مختلف را با یکدیگر به کار بگیرد که این وظایف شامل موارد زیر میباشند:
- بررسی وجود کتاب
- بررسی تعداد موجود یک کتاب در کتابخانه
- بررسی وضعیت امانی کتاب (آیا کتاب در دست کسی از قبل امانت است؟ یا کتاب برای امانت آزاد است؟)
- در صورتی که کتابی بیش از زمان مورد نظر در دست کسی امانت است، با یک پیامک از او بخواهیم که کتاب را بازگرداند.
در کد زیر ما قصد داریم نمونهای از اجرای این الگو را ببینیم. ابتدا سه کلاس اطلاعاتی زیر را ایجاد میکنیم:
کلاس کتاب Book:
class Book { public int Id { get; set; } public string Title { get; set; } public int Quantity { get; set; } public bool IsLoanable { get; set; } }
کلاس کاربر User
class User { public int Id { get; set; } public string Title { get; set; } public string CellPhoneNumber { get; set; } }
کلاس امانت Loan
class Loan { public DateTime ExpiredDate { get; set; } public User User { get; set; } }
بعد از آن سه کلاس را برای مدیریت کتاب، مدیریت امانت و مدیریت پیامکی، ایجاد میکنیم:
کلاس کتاب BookManager:
class BookManager { public Book GetBook(int id) { return new Book() { Id=id, Title = "a book", Quantity = 3, IsLoanable = true }; } }
کلاس LoanManager برای مدیریت امانتها
public int IsLoan(int bookId) { return 2; } public List<Loan> GetLoans(int bookId) { return new List<Loan>() { new Loan() { ExpiredDate = DateTime.Now.AddDays(-15), User = new User() { Id = 2, Title = "User1", CellPhoneNumber = "342342424" } }, new Loan() { ExpiredDate = DateTime.Now.AddDays(5), User = new User() { Id = 56, Title = "User56", CellPhoneNumber = "324324324324" } } }; }
در نهایت سومی کلاس مدیریتی برای پیامک هاست:
class SmsManager { public void SendMessage(string number) { Console.WriteLine("please take back the book to the library : "+number); } }
و در کلاس Facade داریم
class FacadeBookLoan { private readonly BookManager _bookManager; private readonly LoanManager _loanManager; private readonly SmsManager _smsManager; public FacadeBookLoan() { _bookManager = new BookManager(); _loanManager=new LoanManager(); _smsManager=new SmsManager(); } public int IsLoanable(int bookId) { var book = _bookManager.GetBook(2); if (book == null) return -2; if (!book.IsLoanable) return -1; var howManyBookIsLoaned = _loanManager.IsLoan(bookId); if(howManyBookIsLoaned>0) ManageLoaners(bookId); return book.Quantity - howManyBookIsLoaned; } private void ManageLoaners(int bookId) { var loans = _loanManager.GetLoans(bookId); foreach (var loan in loans) { if (loan.ExpiredDate > DateTime.Now) { _smsManager.SendMessage(loan.User.CellPhoneNumber); } } } }
کد بدنه اصلی برنامه:
var myfacade=new FacadeBookLoan(); var loansCount= myfacade.IsLoanable(2); Console.WriteLine(loansCount > 0 ? "you can loan the book" : "you can't loan the book");
please take back the book to the library : 324324324324 you can loan the book