مطالب دوره‌ها
لغو Lazy Loading در حین کار با AutoMapper و Entity Framework
پیشنیازها
- مطالعه‌ی مطالب گروه AutoMapper در سایت، دید خوبی را برای شروع به کار با آن فراهم می‌کنند و در اینجا قصد تکرار این مباحث پایه‌ای را نخواهیم داشت. هدف بیشتر بررسی یک سری نکات پیشرفته‌تر و عمیق‌تر است از کار با AutoMapper.
- آشنایی با Lazy loading و Eager loading در حین کار با EF


ساختار و پیشنیازهای برنامه‌ی مطلب جاری

جهت سهولت پیگیری مطلب و تمرکز بیشتر بر روی مفاهیم اصلی مورد بحث، یک برنامه‌ی کنسول را آغاز کرده و سپس بسته‌های نیوگت ذیل را به آن اضافه کنید:
PM> install-package AutoMapper
PM> install-package EntityFramework
به این ترتیب بسته‌های AutoMapper و EF به پروژه‌ی جاری اضافه خواهند شد.


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

در اینجا ساختار جداول مطالب یک بلاگ را به همراه نویسندگان آن‌ها، مشاهده می‌کنید:
public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
 
    [ForeignKey("UserId")]
    public virtual User User { get; set; }
    public int UserId { get; set; }
}

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
 
    public virtual ICollection<BlogPost> BlogPosts { get; set; }
}
هر کاربر می‌تواند تعدادی مطلب تهیه کند و هر مطلب توسط یک کاربر نوشته شده‌است.


هدف از این مثال

فرض کنید اطلاعاتی که قرار است به کاربر نمایش داده شوند، توسط ViewModel ذیل تهیه می‌شود:
public class UserViewModel
{
    public int Id { set; get; }
    public string Name { set; get; }
 
    public ICollection<BlogPost> BlogPosts { get; set; }
}
در اینجا می‌خواهیم اولین کاربر ثبت شده را یافته و سپس لیست مطالب آن‌را نمایش دهیم. همچنین می‌خواهیم این کوئری تهیه شده به صورت خودکار اطلاعاتش را بر اساس ساختار ViewModel ایی که مشخص کردیم (و این ViewModel الزاما تمام عناصر آن با عناصر مدل اصلی یکی نیست)، بازگشت دهیم.


تهیه نگاشت‌های AutoMapper

برای مدیریت بهتر نگاشت‌های AutoMapper توصیه شده‌است که کلاس‌های Profile ایی را به شکل ذیل تهیه کنیم:
public class TestProfile : Profile
{
    protected override void Configure()
    {
        this.CreateMap<User, UserViewModel>();
    }
 
    public override string ProfileName
    {
        get { return this.GetType().Name; }
    }
}
کار با ارث بری از کلاس پایه Profile کتابخانه‌ی AutoMapper شروع می‌شود. سپس باید متد Configure آن‌را بازنویسی کنیم. در اینجا می‌توان با استفاده از متدی مانند Create مشخص کنیم که قرار است اطلاعاتی با ساختار شیء User، به اطلاعاتی با ساختار از نوع شیء UserViewModel به صورت خودکار نگاشت شوند.


ثبت و معرفی پروفایل‌های AutoMapper

پس از تهیه‌ی پروفایل مورد نیاز، در ابتدای برنامه با استفاده از متد Mapper.Initialize، کار ثبت این تنظیمات صورت خواهد گرفت:
Mapper.Initialize(cfg => // In Application_Start()
{
    cfg.AddProfile<TestProfile>();
});


روش متداول کار با AutoMapper جهت نگاشت اطلاعات User به ViewModel آن

در ادامه به نحو متداولی، ابتدا اولین کاربر ثبت شده را یافته و سپس با استفاده از متد Mapper.Map اطلاعات این شیء user به ViewModel آن نگاشت می‌شود:
using (var context = new MyContext())
{
    var user1 = context.Users.FirstOrDefault();
    if (user1 != null)
    {
        var uiUser = new UserViewModel();
        Mapper.Map(source: user1, destination: uiUser);
 
        Console.WriteLine(uiUser.Name);
        foreach (var post in uiUser.BlogPosts)
        {
            Console.WriteLine(post.Title);
        }
    }
}
تا اینجا اگر برنامه را اجرا کنید، مشکلی را مشاهده نخواهید کرد، اما این کدها سبب اجرای حداقل دو کوئری خواهند شد:
الف) یافتن اولین کاربر
ب) واکشی لیست مطالب او در یک کوئری دیگر


کاهش تعداد رفت و برگشت‌ها به سرور با استفاده از متدهای ویژه‌ی AutoMapper

در حالت متداول کار با EF، با استفاده از متد Include می‌توان این Lazy loading را لغو کرد و در همان اولین کوئری، مطالب کاربر یافت شده را نیز دریافت نمود:
 var user1 = context.Users.Include(user => user.BlogPosts).FirstOrDefault();
و سپس این اطلاعات را توسط AutoMapper نگاشت کرد.
در این حالت، AutoMapper برای ساده سازی این مراحل، متدهای Project To را معرفی کرده‌است:
 var uiUser = context.Users.Project().To<UserViewModel>().FirstOrDefault();
در اینجا نیز Lazy loading لغو شده و به صورت خودکار جوینی به جدول مطالب کاربران ایجاد خواهد شد.
بنابراین با استفاده از متد‌های Project To می‌توان از ذکر Includeهای EF صرفنظر کرد و همچنین دیگر نیازی به نوشتن متد Select جهت نگاشت دستی خواص مورد نظر به خواص ViewModel نیست.

کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید:
AM_Sample01.zip
مطالب
ارتقاء فایل‌های آغازین برنامه‌های ASP.NET Core 5x به 6x
اگر یک پروژه‌ی جدید ASP.NET Core 6x را شروع کنیم، دو فایل قدیمی Program.cs و Startup.cs آن یکی شده‌اند و اینبار فقط یک Program.cs قابل مشاهده‌است؛ با چنین محتوای ساده شده‌ای:
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();
که مفاهیم C# 10.0 مانند «ساده سازی تعریف فضاهای نام در C# 10.0» و «کاهش تعداد بار تعریف using‌ها در C# 10.0 و NET 6.0.» در آن‌ها نیز قابل مشاهده‌است. همچنین در اینجا، تمام تنظیمات WebApplication هم قرار خواهند گرفت؛ عنوان کرده‌اند که از ابتدا هم این تنظیمات در اصل متعلق به همینجا بوده‌اند، چرا تمام آن‌ها را داخل یک فایل اسکریپت مانند قرار ندهیم و تعداد لایه‌های abstractions را کاهش ندهیم؟
البته این روش شاید برای برنامه‌های کوچک جالب به‌نظر برسد، اما برای برنامه‌های بزرگتر می‌توان به گزینه‌های زیر نیز توجه داشت.


گزینه‌ی ارتقاء 1: هیچ کاری نکنید!

اگر می‌خواهید برنامه‌های NET 5. خود را به دات نت 6 ارتقاء دهید و نگران هستید که با دو فایل قدیمی Program.cs و Startup.cs آن باید چکار کنیم، پاسخ ساده‌ی ‌آن این است: هیچ کاری نکنید!
شیوه‌ی قدیمی مبتنی بر generic host و Startup، کاملا در دات نت 6 پشتیبانی می‌شوند؛ از این جهت که WebApplication جدید دات نت 6، صرفا یک محصور کننده‌ی پیچیدگی‌های generic host است. بنابراین برای ارتقاء پروژه‌های ASP.NET Core 5x به 6x، تنها کافی است فایل csproj خود را ویرایش کرده و TargetFramework آن‌را به net6.0 تغییر دهید. پس از آن Program.cs و Stratup.cs قبلی شما بدون هیچ مشکلی و بدون نیاز به هیچ تغییری، با دات نت 6 هم کار خواهند کرد.
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
      <TargetFramework>net6.0</TargetFramework>
   </PropertyGroup>
</Project>


گزینه‌ی ارتقاء 2: از کلاس Startup قبلی خود استفاده‌ی مجدد کنید

اما اگر واقعا علاقمندیم که از WebApplication جدید استفاده کنیم و همچنین نمی‌خواهیم همه‌چیز را داخل Program.cs قرار دهیم، چکار باید کرد؟
فرض کنید ساختار کلاس Startup موجود شما چنین شکلی را دارد که به همراه سازنده‌ای است که IConfigurationRoot را دریافت می‌کند و همچنین دارای دو متد ConfigureServices و Configure نیز هست:
public class Startup
{
    public Startup(IConfigurationRoot configuration)
    {
        Configuration = configuration;
    }

    public IConfigurationRoot Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        // ...
    }

    public void Configure(IApplicationBuilder app, IHostApplicationLifetime lifetime)
    {
        // ...
    }
}
تا پیش از دات نت 6، متد <UseStartup<T که در فایل Program.cs قرار داشت، کار استفاده از تنظیمات کلاس فوق را به صورت خودکار انجام می‌داد. این متد دیگر در سیستم جدید مبتنی بر WebApplication دات نت 6 وجود ندارد، اما می‌توان به صورت زیر آن‌را برگرداند:
var builder = WebApplication.CreateBuilder(args);
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);
var app = builder.Build();
startup.Configure(app, app.Lifetime);
app.Run();
در اینجا روش نمونه سازی دستی کلاس Startup قدیمی را مشاهده می‌کنید که به همراه فراخوانی دستی دو متد ConfigureServices و Configure آن نیز هست. به این ترتیب می‌توان از کلاس قدیمی آغازین برنامه‌های دات نت 5، در برنامه‌های دات نت 6 نیز استفاده کرد.


گزینه‌ی ارتقاء 3: استفاده از متدهای محلی در فایل Program.cs

اگر بخواهیم سیستم طراحی مینی‌مال دات نت 6 را رعایت کنیم، می‌توان بجای ایجاد یک فایل Startup مجزا، متدهای تنظیمی آن‌را به صورت تعدادی متد محلی، در همان فایل Program.cs قرار داد تا کمی ساختار پیدا کند(!)؛ چیزی شبیه به طراحی زیر که همان متدهای قبلی فایل Startup را در انتهای فایل Program.cs جاری به صورت متدهایی محلی، مشاهده می‌کنید؛ به همراه متدهای اختیاری دیگری برای تنظیم میان‌افزارها و یا endpoints:
var builder = WebApplication.CreateBuilder(args);
ConfigureConfiguration(builder.configuration);
ConfigureServices(builder.Services);
var app = builder.Build();
ConfigureMiddleware(app, app.Services);
ConfigureEndpoints(app, app.Services);
app.Run();

void ConfigureConfiguration(ConfigurationManager configuration) => { }

void ConfigureServices(IServiceCollection services) => { }

void ConfigureMiddleware(IApplicationBuilder app, IServiceProvider services) => { }

void ConfigureEndpoints(IEndpointRouteBuilder app, IServiceProvider services) => { }
در کل این قالب جدید دات نت 6، هیچ نوع الگو و یا پیشنیاز خاصی را جهت انجام تنظیمات آغازین برنامه توصیه نمی‌کند؛ از این رو می‌توان به هر نحوی که علاقمند بودیم، آن‌را شکل دهیم.
مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت دوم - ایجاد ساختار اولیه‌ی مثال این سری
در این قسمت قصد داریم ساختار مقدماتی مثال این سری را که لیستی از تصاویر آپلود شده‌ی توسط کاربران مختلف را نمایش می‌دهد، بدون افزودن مباحث امنیتی و سطوح دسترسی کاربران وارد شده‌ی به سیستم، تشکیل دهیم. در قسمت‌های بعدی، به تدریج آن‌را با قابلیت‌های مختلف IdentityServer 4x یکپارچه خواهیم کرد. در اینجا فرض بر این است که حداقل SDK نگارش 2.1.401 را پیشتر نصب کرده‌اید.


بررسی ساختار WebAPI مقدماتی مثال این سری


این پروژه‌ی مقدماتی که هنوز قسمت‌های اعتبارسنجی به آن اضافه نشده‌اند، از دو قسمت WebApi و MvcClient تشکیل می‌شود.
کار قسمت WebApi، ارائه‌ی یک Restful-API برای کار با گالری تصاویر است. برای اجرای آن وارد پوشه‌ی src\WebApi\ImageGallery.WebApi.WebApp شده و ابتدا فایل restore.bat و سپس dotnet_run.bat را اجرا کنید.
در این حالت برنامه بر روی پورت 7001 در دسترس خواهد بود:


این پورت نیز در فایل Properties\launchSettings.json تنظیم شده‌است تا با پورت کلاینت MVC تهیه شده، تداخل نکند.
کار این سرویس، ارائه‌ی ImagesController است که توسط آن می‌توان لیستی از تصاویر موجود، اطلاعات یک تصویر و همچنین کار ثبت، ویرایش و حذف تصاویر را انجام داد.
در این Solution، رکوردهای تصاویری که در بانک اطلاعاتی ذخیره می‌شوند، یک چنین ساختاری را دارند:
using System;
using System.ComponentModel.DataAnnotations;

namespace ImageGallery.WebApi.DomainClasses
{
    public class Image
    {
        [Key]
        public Guid Id { get; set; }

        [Required]
        [MaxLength(150)]
        public string Title { get; set; }

        [Required]
        [MaxLength(200)]
        public string FileName { get; set; }

        [Required]
        [MaxLength(50)]
        public string OwnerId { get; set; }
    }
}
همانطور که ملاحظه می‌کنید در اینجا OwnerId نیز در نظر گرفته شده‌است تا بتوان پس از اعمال مباحث اعتبارسنجی، تصاویر را از کاربری خاص دریافت و همچنین صرفا تصاویر متعلق به او را به آن کاربر خاص نمایش داد.
در این قسمت توسط کلاس ImageConfiguration کار مقدار دهی اولیه‌ی بانک اطلاعاتی به کمک متد HasData مربوط به EF Core 2.1 صورت گرفته‌است و به این ترتیب می‌توان برنامه را برای نمایش مقدماتی جاری، بدون داشتن سیستم اعتبارسنجی و مفاهیم کاربران، نمایش داد.
این قسمت از Solution، به نحو زیر تشکیل شده‌است:
- ImageGallery.WebApi.DataLayer
در اینجا کار تشکیل DbContext برنامه و همچنین مقدار دهی اولیه‌ی بانک اطلاعاتی و تنظیمات Migrations قرار گرفته‌اند.
- ImageGallery.WebApi.DomainClasses
در این پروژه کلاس‌های موجودیت‌های متناظر با جداول بانک اطلاعاتی قرار می‌گیرند.
- ImageGallery.WebApi.Mappings
این پروژه کار تهیه نگاشت‌های AutoMapper برنامه را انجام می‌دهد؛ نگاشت‌هایی بین Models و DomainClasses که در ImagesController از آن‌ها استفاده می‌شود.
- ImageGallery.WebApi.Models
در این پروژه همان DTO's پروژه قرار گرفته‌اند. جهت رعایت مسایل امنیتی نباید کلاس موجودیت Image فوق را مستقیما در معرض دید API عمومی قرار داد. به همین جهت تعدادی Model در اینجا تعریف شده‌اند که هم برای ثبت، ویرایش و حذف اطلاعات بکار می‌روند و هم جهت گزارشگیری از رکوردهای موجود جدول تصاویر.
- ImageGallery.WebApi.Services
در این پروژه کار با DbContext انجام شده و توسط آن اطلاعات تصاویر به بانک اطلاعاتی اضافه شده و یا واکشی می‌شوند.
- ImageGallery.WebApi.WebApp
این پروژه، همان پروژه‌ی اصلی است که سایر قسمت‌های یاد شده را در کنار هم قرار داده و به صورت یک Restful-API ارائه می‌دهد.



بررسی ساختار MvcClient مقدماتی مثال این سری

پس از اجرای WebAPI و آماده بودن آن جهت استفاده، اکنون یک کلاینت ASP.NET Core MVC را جهت کار با امکانات ImagesController آن، تدارک دیده‌ایم.
برای اجرای آن وارد پوشه‌ی src\MvcClient\ImageGallery.MvcClient.WebApp شده و ابتدا فایل restore.bat و سپس dotnet_run.bat را اجرا کنید.
در این حالت برنامه بر روی پورت 5001 در دسترس خواهد بود:


این پورت نیز در فایل Properties\launchSettings.json تنظیم شده‌است.


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

این قسمت از Solution به نحو زیر تشکیل شده‌است:
- ImageGallery.MvcClient.Services
در اینجا یک Typed HTTP Client مخصوص NET Core 2.1. را تهیه کرده‌ایم. این سرویس جهت دسترسی به آدرس https://localhost:7001 که WebAPI برنامه در آن قرار دارد، تشکیل شده‌است. روش ثبت مخصوص آن‌را نیز در فایل آغازین پروژه‌ی MvcClient.WebApp توسط متد services.AddHttpClient ملاحظه می‌کنید.
- ImageGallery.MvcClient.ViewModels
مدل‌های متناظر با ساختار Viewهای Razor برنامه‌ی وب، در اینجا قرار می‌گیرند.
- ImageGallery.MvcClient.WebApp
این پروژه، همان پروژه‌ی اصلی است که سایر قسمت‌های یاد شده را در کنار هم قرار داده و به صورت یک برنامه‌ی MVC قابل مرور در مرورگر، ارائه می‌دهد.

کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید.
برای اجرای آن ابتدا باید پروژه‌ی WebApi.WebApp را اجرا کنید و سپس پروژه‌ی MvcClient.WebApp.
مطالب
طراحی و پیاده سازی مکانیزم مدیریت Transactionها در ServiceLayer

هدف ارائه راه حلی برای مدیریت Transactionها به عنوان یک Cross Cutting Concern، توسط ApplicationServiceها می‌باشد. 

پیش نیازها:

پیش فرض ما این است که شما از EF به عنوان OR-Mapper استفاده می‌کنید و الگوی Context Per Request را پیاده سازی کرده اید یا از طریق پیاده سازی الگوی Container Per Request به داشتن Context یکتا برای هر درخواست رسیده اید.
کتابخانه StructureMap.Mvc5 پیاده سازی از الگوی Container Per Request را با استفاده از امکانات Nested Container مربوط به StructureMap ارائه می‌دهد. اشیاء موجود در Nested Container طول عمر Singleton دارند.

ایده کار به این صورت هست که توسط یک Interceptor، به هنگام ورود به متد موجود در یک ApplicationService که با TransactionalAttribute تزئین شده است، یک تراکنش ایجاد شده و بعد از اتمام کار متد مورد نظر، در صورت عدم بروز استثناء، Commit و در غیر این صورت Rollback شود. حال اگر یک متد تراکنشی، داخل خود از متد تراکنشی دیگری استفاده کند، صرفا متد بیرونی تراکنش را ایجاد می‌کند و متد داخلی از همان تراکنش استفاده خواهد کرد و اصطلاحا  این تراکنش به صورت Ambient Transaction می باشد. 


واسط ITransaction

    public interface ITransaction : IDisposable
    {
        void Commit();
        void Rollback();
    }

واسط بالا 3 متد را که برای مدیریت تراکنش لازم می‌باشد، در اختیار استفاده کننده قرار می‌دهد.


واسط IUnitOfWork

    public interface IUnitOfWork : IDisposable
    {
        ...

        ITransaction BeginTransaction(IsolationLevel isolationLevel = IsolationLevel.Snapshot);
        ITransaction Transaction { get; }
        IDbConnection Connection { get; }
        bool HasTransaction { get; }
    }

اعضای جدید واسط IUnitOfWork کاملا مشخص هستند.

پیاده سازی واسط ITransaction، توسط یک Nested Type در دل کلاس DbContextBase انجام می‌گیرد.

 public abstract class DbContextBase : DbContext
    {
        ...

        #region Fields
        
        private ITransaction _currenTransaction;

        #endregion

        #region NestedTypes

        private class DbContextTransactionAdapter : ITransaction
        {
            private DbContextTransaction _transaction;

            public DbContextTransactionAdapter(DbContextTransaction transaction)
            {
                Guard.NotNull(transaction, nameof(transaction));

                _transaction = transaction;
            }

            public void Commit()
            {
                _transaction?.Commit();
            }

            public void Rollback()
            {
                if (_transaction?.UnderlyingTransaction.Connection != null)
                    _transaction.Rollback();
            }

            public void Dispose()
            {
                _transaction?.Dispose();
                _transaction = null;
            }
        }

        #endregion

        #region Public Methods
        ...

        public ITransaction BeginTransaction(IsolationLevel isolationLevel = IsolationLevel.ReadCommitted)
        {
            if (_currenTransaction != null) return _currenTransaction;

            return _currenTransaction = new DbContextTransactionAdapter(Database.BeginTransaction(isolationLevel));
        }
        #endregion

        #region Properties
        ...

        public ITransaction Transaction => _currenTransaction;
        public IDbConnection Connection => Database.Connection;
        public bool HasTransaction => _currenTransaction != null;

        #endregion
}

public class ApplicationDbContext : DbContextBase, IUnitOfWork, ITransientDependency
{
     
}

کلاس DbContextTransactionAdapter همانطور که از نام آن مشخص می‌باشد، پیاده سازی از الگوی Adapter برای وفق دادن DbContextTransaction با واسط ITransaction، می‌باشد. متد BeginTransaction در صورتی که تراکنشی برای وهله جاری DbContext ایجاد نشده باشد، تراکنشی را ایجاد کرده و فیلد currentTransaction_ را نیز مقدار دهی می‌کند. 


TransactionalAttribute

    [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
    public sealed class TransactionalAttribute : Attribute
    {
        public IsolationLevel IsolationLevel { get; set; } = IsolationLevel.ReadCommitted;
        public TimeSpan? Timeout { get; set; }
    }

TransactionInterceptor

    public class TransactionInterceptor : ISyncInterceptionBehavior
    {
        private readonly IUnitOfWork _unitOfWork;

        public TransactionInterceptor(IUnitOfWork unitOfWork)
        {
            _unitOfWork = unitOfWork;
        }
        public IMethodInvocationResult Intercept(ISyncMethodInvocation methodInvocation)
        {
            var transactionAttribute = GetTransactionaAttributeOrNull(methodInvocation.InstanceMethodInfo);

            if (transactionAttribute == null || _unitOfWork.HasTransaction) return methodInvocation.InvokeNext();

            using (var transaction = _unitOfWork.BeginTransaction(transactionAttribute.IsolationLevel))
            {
                var result = methodInvocation.InvokeNext();

                if (result.Successful)
                    transaction.Commit();
                else
                {
                    transaction.Rollback();
                }

                return result;
            }
        }

        private static TransactionalAttribute GetTransactionaAttributeOrNull(MemberInfo methodInfo)
        {
            var transactionalAttribute =
                ReflectionHelper.GetAttributesOfMemberAndDeclaringType<TransactionalAttribute>(
                    methodInfo
                ).FirstOrDefault();

            return transactionalAttribute;
        }
    }

واسط ISyncInterceptionBehavior، مربوط می‌شود به کتابخانه جانبی دیگری که برای AOP توسط تیم StructureMap به نام StructureMap.DynamicInterception ارائه شده‌است. در متد Intercept، ابتدا چک می‌شود که که آیا این متد با TransactionAttribute تزئین شده و طی درخواست جاری برای Context جاری تراکنشی ایجاد نشده باشد؛ سپس تراکنش جدیدی ایجاد شده و بدنه اصلی متد اجرا می‌شود و نهایتا در صورت موفقیت آمیز بودن عملیات، تراکنش مورد نظر Commit می‌شود.

در آخر لازم است این Interceptor در تنظیمات اولیه StructureMap به شکل زیر معرفی شود:

Policies.Interceptors(new DynamicProxyInterceptorPolicy(
                type => typeof(IApplicationService).IsAssignableFrom(type), typeof(AuthorizationInterceptor), typeof(TransactionInterceptor), typeof(ValidationInterceptor)));



نکته: فرض کنید در بدنه اکشن متد یک کنترلر ASP.NET MVC یا ASP.NET Core، دو متد تراکنشی فراخوانی شود؛ در این صورت شاید لازم باشد که این دو متد طی یک تراکنش واحد به جای تراکنش‌های مجزا، اجرا شوند؛ بنابراین نیاز است از الگوی Transaction Per Request استفاده شود. برای این کار می‌توان یک ActionFilterAttribute سفارشی ایجاد کرد که ایجاد کننده تراکنش باشد و متدهای داخلی که هر کدام جدا تراکنشی بودند، نیز از تراکنش ایجاد شده استفاده کنند.

مطالب
مقدمه‌ای بر Docker، قسمت دوم
در قسمت قبلی با مفاهیم اولیه‌ی داکر آشنا شدیم و در این قسمت بیشتر به مباحث عملی آن خواهیم پرداخت. ضمن اینکه طریقه‌ی نصب داکر نیز بسیار ساده‌است و برای مطالعه‌ی بیشتر به سایت مرجع آن مراجعه بفرمایید (برای ویندوز، مک و لینوکس قسمت‌های مجزایی تعبیه شده و نصب آن آموزش داده شده‌است).
در قسمت قبلی با Volume آشنا شدیم؛ اکنون قصد داریم آن را اجرایی نموده و برنامه‌ی خود را بر روی آن اجرا نماییم. عملا با استفاده از Volume، قابلیت این را خواهید داشت که از Container ایجاد شده، با استفاده از volume، اشاره‌گری را به source code خود بر روی ماشین محلی داشته باشید و کد خود را بر روی آن اجرا نمایید.
مزایای استفاده از Volume
Volumeها بر روی Containerهای ویندوزی و لینوکسی اجرا میشوند.
قابلیت اشتراک گذاری volume بین container‌های مختلف وجود دارد.
Volumeها persisted هستند و حتی بعد از حذف container پایدار باقی می‌مانند و قابلیت استفاده‌ی مجدد را خواهند داشت.

ما طبق شکل فوق، می‌توانیم درون یک container، یک volume داشته باشیم و وقتی چیزی را درون آن می‌نویسیم، عملا داریم در قسمت خاصی به نام Docker Host عمل write کردن را انجام میدهیم که باعث میشود داکر متوجه آن شود. وقتی اسمی را به یک Volume انتساب می‌دهیم همانند /var/www، در واقع یک اسم مستعار (alias) می‌باشد که اشاره میکند به این Docker host موجود.
 
میخواهیم در این قسمت یک اپلیکیشن Nodejsِی را با استفاده از Volume بر روی Docker Container اجرا نماییم.
ابتدا دستور زیر را وارد کرده تا آخرین نسخه‌ی تصویر Nodejs را بر روی سیستم خود دریافت نمایید:
docker pull node
بعد از دریافت آن از طریق دستور زیر، لیست Image‌های cache شده بر روی سیستم خود را می‌توانید ببینید:
docker images
حال باید چنین چیزی را بر روی ترمینال خود مشاهده کنید:


در ادامه نیاز داریم یک دایرکتوری را ایجاد کرده و فایل index.js را درون آن بسازیم:

mkdir testapp
cd testapp
touch index.js
npm init
npm i express --save

یک دایرکتوری را ساختیم و همچنین express را نیز نصب نمودیم.

اکنون package.json را باز کرده و این قسمت را جایگزین کنید؛ تا با استفاده از npm start، برنامه اجرا شود:

"scripts": {
    "start": "node index"
  }

index.js را باز کرده و کد‌های زیر را وارد کنید:

const express = require('express')
const app = express()

const PORT = 3000;

app.get('/', function (req, res) {
  res.send('Hello World')
})

app.listen(PORT, function () {
  console.log(`listening on port ${PORT}!`)
})

همه چیز خیلی ساده در نظر گرفته شده است. از فریمورک express استفاده کردیم و یک سرور را بر روی پورت 3000 اجرا کرده و همچنین بر روی آدرس "/" یک سطر کد Hello World اجرا می‌شود.

خوب، فرض کنید قصد داریم با استفاده از volume، کد فوق را بر روی container اجرا کنیم.

برای اجرا شدن این کد‌ها بر روی Volume، دستور زیر را درون ترمینال خود وارد کنید:

docker run -d -p 3030:3000 -v $(pwd):/var/www -w "/var/www" node npm start

شرح دستور فوق:

دستور ساخت container با استفاده از ارگومان run

d- برای اجرا شدن container در حالت detached، باعث میشود اجرا شدن آن در حالت بک‌گراند بوده و بتوانید بر روی ترمینال مربوطه، دستورات دیگری را وارد نمایید.

p- پورت داخلی و خارجی را مشخص میکند. در اینجا پورت داخلی، 3000 و خارجی، 3030 میباشد.

آرگومان v- برای ساخت volume و (pwd)$ دایرکتوری جاری را بر روی سیستم شما، نشان خواهد داد. بعد از آن /var/www یک دایرکتوری فرضی است (هر آدرس دلخواهی را میتوانیم داشته باشیم) که قرار است بوسیله‌یdocker ساخته شود و از آن اشاره‌گری به دایرکتوری جاری بر روی ماشین محلی زده شود.

w- همان WorkingDirectory می‌باشد. بدلیل اینکه میخواهیم بر روی container به دایرکتوری که کد‌های ما وجود دارد، وارد شود.

بعد از آن اسم image ای را که قرار است از آن استفاده شود، آورده تا container ایجاد شود.

و بعد از npm start برنامه را اجرا خواهد کرد.

پس از اجرا کردن دستور فوق، container ایجاد میشود و قابلیت اجرایی دارد (با استفاده از ip و port خارجی بر روی browser میتوانیم برنامه را مشاهده کنیم).

حال با استفاده از دستور زیر لیست container‌های اجرایی را مشاهده خواهیم کرد:

docker ps

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

حتی میتوانید به راحتی درون container را با استفاده از دستور زیر مشاهده کنید:

docker exec -it 6003 bash

6003 ابتدای کلید container ایجاد شده‌است و با استفاده از bash وارد محیط command line در container ایجاد شده خواهیم شد و دسترسی کاملی خواهیم داشت.

بطور مثال برای دیدن کد‌های index.js بر روی container ایجاد شده، بعد از دستور فوق، command زیر را وارد نمایید:

cat index.js

 جالب است بدانید از آنجائیکه container از طریق volume به دایرکتوری محلی شما لینک شده‌است، به محض اینکه بر روی سیستم خود کدی را تغییر داده و دوباره دستور فوق را اجرا کنید، تغییرات را مشاهده خواهید کرد.

برای متوقف کردن container از دستور زیر باید استفاده کرد:

docker stop 6003

نکته: 6003 آی دی container است و برای اجرای مجدد آن docker start 6003

بعد از متوقف کردن container و اجرای دستور docker ps متوجه خواهید شد که دیگر Container در لیست containerهای باز نیست.

با استفاده از دستور زیر به لیست تمامی Container‌ها چه در حال اجرا و چه متوقف شده، دسترسی خواهیم داشت:

docker ps -a

برای حذف container نیز از دستور زیر استفاده میکنیم:

docker rm -v 6003

rm برای حذف container و همچنین v- برای حذف volume میباشد.

مطالب
بررسی مفهوم Event bubbling در جی کوئری و تاثیر آن بر کارآیی کدهای نوشته شده
Event bubbling یا جوشیدن رویدادها به مفهوم انتقال رویدادهای رخ داده در یک المنت به سمت المنت یا المنت‌های والد می‌باشد. برای مثال با کلیک بر روی یک المنت در صفحه، رویداد کلیک هم در همان المنت اجرا خواهد شد و هم در المنت‌های والد.
ساختار سند زیر را در نظر بگیرید:
<div id="parent">
    <div id="child1">
        <div id="child2">
            <div id="child3"></div>
        </div>
    </div>
</div>
حال اگر برای هرکدام از divهای موجود در سند، یک هندلر برای مدیریت رویداد کلیک نوشته شود و کاربر بر روی child3 کلیک کند، به ترتیب ابتدا رویداد مربوط به المنت child3 سپس child2 سپس child1 و در نهایت parent اجرا خواهد شد. یعنی با کلیک بر روی child3، تمامی هندلرهای کلیک اجرا خواهند شد. دلیل اینکار همان مفهوم Event bubbling است.
Event bubbling فقط مختص صفحات وب نیست؛ بلکه در تمامی سیستم عامل‌ها یکی از مفاهیم مدیریت رخدادها(Events) است. حتی در برنامه‌های مبتنی بر ویندوز فرم هم شما با این مفهوم برخورد کرده‌اید.
در صفحات وب، در نهایت رویدادها به شیء Window منتقل می‌شوند و در یک وب فرم، به From اصلی برنامه.
حال با این مقدمه به سراغ بهینه سازی کدهای نوشته شده‌ی خود می‌رویم. اگر از کتابخانه‌ی جی‌کوئری استفاده کرده باشید، حتما از رویدادهای مختلف ماوس و صفحه کلید بهره برده‌اید. تصور برنامه‌ای که از رویدادها استفاده نکند و باید با کاربر در تعامل باشد، غیرممکن است؛ زیرا این رویدادها هستند که درخواست‌های کاربر را به برنامه منتقل می‌کنند.
به قطعه کد زیر توجه کنید:
$('#parent').on('click', function (event) {

});

$('#child1').on('click', function (event) {

});

$('#child2').on('click', function (event) {

});
ما یک هندلر برای مدیریت رویداد کلیک المنت parent نوشته‌ایم؛ یکی برای المنت child1 و یکی دیگر برای child2. با استفاده از مفهوم جوشیدن رخدادها می‌توانیم هر سه هندلر را حذف و به یک هندلر تبدیل کنیم!
$(document).on('click', '#parent, #child1, #child2, #child3', function (event) {

});
شاید بپرسید مزیت اینکار چیست؟ نکته‌ی کلیدی در همینجاست. میزان حافظه‌ی مصرفی مدیریت یک رخداد، به مراتب کمتر از چندین رخداد است.
در واقع شما فقط یک هندلر را ثبت و تمامی کارهای لازم را به آن می‌سپارید. شدیدا توصیه می‌شود که در نوشتن کدهای خود از ایجاد هندلر بر روی هر عنصر خودداری کنید.
برای مثال اگر شما در صفحه‌ی مدیریت پست‌ها قرار دارید و برای ویرایش هر پست دکمه‌ای را تعیین کرده باشید به جای نوشتن کدی مانند زیر:
$('.post .edit').on('click', function (event) {

});
از نسخه‌ی بهینه شده‌ی آن استفاده کنید:
$(document).on('click', '.post .edit', function (event) {

});
تصور کنید شما در همین صفحه 50 پست را به کاربر نشان داده باشید و اگر از کد بالا استفاده کنید، به ازای هر 50 دکمه‌ی ویرایش، یک هندلر برای رویداد کلیک خواهید داشت. حالا اگر از کد پایین استفاده کنید، تنها یک هندلر برای 50 رویداد خواهید داشت.
همان صفحه‌ی مدیریت پست را در نظر بگیرید. 50 پست داریم. هر کدام یک دکمه‌ی ویرایش، حذف، امتیازات، کامنتها و کلی ابزار دیگر که همه با رویداد کلیک فعال می‌شوند. چیزی حدود به 300 رویداد را باید ثبت کنید!
این واقعا یک تراژدی بزرگ در مصرف حافظه محسوب می‌شود. پس بهینه‌تر است تا با نوشتن یک رویداد کلیک روی کل شیء سند، از ایجاد هندلرهای اضافی خودداری کنید.

در اینجا دو نکته قابل ذکر است:
1- چگونه از Event bubbling جلوگیری کنیم؟
برخی از اوقات لازم است تا در لایه‌های تو در تو، به ازای هر لایه، کد خاصی اجرا شود. یعنی با کلیک بر روی child3 نمی‌خواهیم رویداد مربوط به parent یا حتی child2 اجرا شوند. در این حالت باید از event.stopPropagation در بدنه‌ی هندلر استفاده کنیم.

2- چگونه می‌توان تشخیص داد که بر روی کدام لایه یا المنت کلیک شده است؟
شما با استفاده از event.event.target، به شیء هدف دسترسی خواهید داشت. برای مثال اگر قصد داشته باشیم که قسمتی از کدهای ما فقط بر روی یک المنت خاص اجرا شوند، می‌توانیم به شکل زیر آنها را تفکیک کنیم:
        var elemnt = $(event.target);
        if (elemnt.attr('id') === 'parent') {
            alert('this is parnet');
        }
        else if (elemnt.attr('id') === 'child2') {
            alert('this is child2');
        }
البته نوشتن شرط برای همه‌ی المنت‌ها در یک هندلر هم باعث طولانی شدن کدها و هم تولید کد اضافه خواهد شد. خوشبختانه جی کوئری، مدیریت و ثبت رخدادها را هوشمندانه انجام می‌دهد. به جای نوشتن شرط، به راحتی کدهای مربوط به هر المنت را در یک رجیستر کننده‌ی جدا بنویسید و در نهایت جی کوئری آن‌ها را برای شما به یک هندلر منتقل خواهد کرد:
$(document).ready(function () {

    $(document).on('click','#parent', function (event) {

    });

    $(document).on('click','#child1', function (event) {

    });

    $(document).on('click','#child2', function (event) {
        event.st
    });

});

یکی دیگر از مهمترین مزایای کدنویسی به شکل فوق اینست که حتی رویدادهای مربوط به اشیایی که به صورت پویا به سند اضافه می‌شوند، اجرا خواهند شد.
در صفحه‌ی اصلی همین سایت بر روی دکمه‌ی بارگزاری بیشتر کلیک کنید. پس از اضافه شدن پست‌ها سعی کنید به یک پست امتیاز دهید. اتفاقی نخواهد افتاد. زیرا برای عناصری که بصورت پویا به صفحه اضافه شده‌اند رویدادی ثبت نشده است، که اگر از کدهای فوق استفاده شود با کمترین هزینه به هدف دلخواه خود خواهیم رسید.
پس همیشه رویدادها را تا حد امکان بر روی عنصر ریشه تعریف کنید.
دیدن لینک زیر برای اجرای یک تست و درک بهتر مطلب خالی از لطف نخواهد بود:
http://jsperf.com/jquery-body-delegate-vs-document-delegate
مطالب
آشنایی با WPF قسمت هفتم: DataContext بخش چهارم
تا قسمت قبلی کنترل لیست را پر نمودیم. در این مقاله قصد داریم آخرین کنترلT یعنی تقویم را بایند کرده و یک نکته از Binding را جهت تکمیل کردن بحث بیان کنیم.

تقویم
در دروس گذشته اطلاعات را از متدی به نام GetPerson دریافت می‌کردیم که اطلاعات آن به شرح زیر است:
  public static Person GetPerson()
        {

            return new Person()
            {
                Name = "Leo",
                Gender = true,
                ImageName = "man.jpg",
                Country = new Country()
                {
                    Id = 3, Name = "Angola" 
                },
                FieldOfWork = new FieldOfWork[] { test.FieldOfWork.Actor, test.FieldOfWork.Producer },
                Date = DateTime.Now.AddMonths(-3)
            };
        }

تاریخ ثبت شده در بالا، به سه ماه قبل از تاریخ فعلی بر می‌گردد و حالا این تاریخ را به خصوصیت DisplayDate تقویم انتساب می‌دهیم:
Calendar DisplayDate="{Binding Date}" Grid.Row="4" Grid.Column="1" HorizontalAlignment="Left" Margin="10">
اگر از برنامه اجرا بگیرد می‌بینید که تقویم روی سه ماه پیش قرار گرفته است؛ ولی تاریخی روی صفحه انتخاب نشده است و دلیل آن هم این است که این خصوصیت، تقویم را به جایی میبرد که آن تاریخ در آن ذکر شده است، ولی تاریخی روی صفحه انتخاب نمی‌کند. به همین علت در اکثر موارد در کنار خاصیت DisplayDate، از خاصیت SelectedDate هم استفاده می‌شود. این خاصیت بر خلاف خاصیت قبلی، تقویم را حرکت نمی‌دهد ولی تاریخ را انتخاب می‌کند. پس در این حالت ما هر دو گزینه را بایند می‌کنیم که هم تقویم به محل تاریخ حرکت کرده و هم تاریخ مد نظر انتخاب شود:
 <Calendar DisplayDate="{Binding Date}" SelectedDate="{Binding Date}" Grid.Row="4" Grid.Column="1" HorizontalAlignment="Left" Margin="10">

ادامه مفاهیم بایندینگ
در قسمت پنجم، دیدیم که چطور می‌توانیم با استفاده از متد OnPropertyName، برنامه را از تغییراتی که در سطح مدل می‌گذرد، آگاه کنیم و این تغییرات جدید را دریافت کرده و اطلاعات نمایش داده شده را به روز کنیم. در اینجا قصد داریم خلاف اینکار را با استفاده از همان متد انجام دهیم. یعنی مدل را از تغییراتی که در سطح UI می‌گذرد، آگاه کنیم.
این مثال را روی خصوصیت Name مدل اجرا می‌کنیم:
در Xaml Editor تگTextBox مربوط به نام شخص را به شکل زیر تغییر می‌دهیم:
  <TextBox Grid.Row="0" Grid.Column="1" Name="Txtname" Text="{Binding Path=Name,Mode=TwoWay}" HorizontalAlignment="Left" Margin="5" Width="200" ></TextBox>

تغییری که در این حالت رخ داده است، افزودن ویژگی به نام Mode است که روی گزینه TwoWay تنظیم شده است. در قسمت‌های قبلی تمامی بایندینگ‌ها به طور پیش فرض روی حالت یک طرفه OneWay قرار داشتند، ولی در اینجا ما بایندینگ را دو طرفه اعمال کرده‌ایم. حال به همین سادگی هر تغییری که در این TextBox رخ دهد به مدل هم اعمال خواهد شد.
حال برای تست این مورد، عنصر زیر را در کنار نام شخص به صفحه اضافه می‌کنیم. یک برچسب متنی که به خاصیت Name متصل است و از تغییراتی که در سطح مدل داده می‌شود، آگاه است:
 <TextBlock Grid.Column="1" Text="{Binding Path=Name}"  Grid.Row="0" VerticalAlignment="Center" HorizontalAlignment="Left" Margin="210,10,0,13" RenderTransformOrigin="0.555,1.283" ></TextBlock>
اینک برنامه را اجرا می‌کنیم و فیلد متنی نام را ویرایش می‌کنیم. اگر فوکوس را از این کنترل بگیریم، می‌بینید که فیلد متنی هم به مقدار جدید تغییر می‌کند. اتفاق جدیدی که در اینجا افتاد این بود که مدل از تغییراتی که در سطح UI رخ داده بود، آگاه شد و بعد از آن فیلد متنی همانطور که قبلا با آن آشنا شده‌ایم از تغییری که در مدل رخ داده است آگاه شده است.


 
از دیگر مقادیر Mode می‌توان به جدول زیر اشاره کرد:
OneWayToSource
در این حالت، مدل از تغییرات سطح UI آگاه می‌شود ولی بقیه کنترل‌ها یا المان‌ها را از تغییرات خود آگاه نمی‌کند. 
OneTime
 در این حالت تنها یکبار مدل داده‌های خود را کنترل کرده (همان پر کردن اولیه داده‌ها) و دیگر هیچ نوع تغییراتی را رصد نمی‌کند.
 
تا به اینجا یک سری پیش نیازها را یاد گرفتیم. ولی روشی را که تا به اینجا استفاده کرده‌ایم یک روش اشتباه و قدیمی است که در winform هم انجام می‌دادیم. یعنی هنوز وابستگی بین رابط کاربری و منطق برنامه وجود دارد. در قسمت بعدی در مورد M-V-VM صحبت خواهیم کرد و از طریق viewmodel ارتباط بین مدل و ویو را ایجاد خواهیم کرد. در این روش دیگر نیازی نیست که بدانید کنترلی به اسم textbox1 وجود دارد یا خیر یا حتی اصلا اسمی دارد یا خیر و این یعنی جدایی رابط کاربری و منطق برنامه و اصل هدف WPF.
دانلود مثال
مطالب
آموزش TypeScript #5
در ادامه مباحث شی گرایی در TypeScript قصد داریم به مباحث مربوط به interface و طریقه استفاده از آن بپردازیم. همانند زبان‌های دات نتی در TypeScript نیز به راحتی می‌توانید interface تعریف کنید. در یک اینترفیس اجازه پیاده سازی هیچ تابعی را ندارید و فقط باید عنوان و پارامتر‌های ورودی و نوع خروجی آن را تعیین کنید. برای تعریف اینترفیس از کلمه کلیدی interface به صورت زیر استفاده خواهیم کرد.
export interface ILogger {
  log(message: string): void;
}
همان طور در پست‌های قبلی مشاهده شد از کلمه کلیدی export برای عمومی کردن اینترفیس استفاده می‌کنیم. یعنی این اینترفیس از بیرون ماژول خود نیز قابل دسترسی است.
حال نیاز به کلاسی داریم که این اینترفیس را پیاده سازی کند. این پیاده سازی به صورت زیر انجام می‌گیرد:
export class Logger implements ILogger
{
}
یا:
export class AnnoyingLogger implements ILogger {
   log(message: string): void{
         alert(message);
     } 
}
همانند دات نت یک کلاس می‌تواند چندین اینترفیس را پیاده سازی کند.(اصطلاحا به این روش explicit implementation یا پیاده سازی صریح می‌گویند)
export class MyClass implements IFirstInterface, ISecondInterface
{

}
*یکی از قابلیت جالب و کارآمد زبان TypeScript این است که در هنگام کار با اینترفیس‌ها حتما نیازی به پیاده سازی صریح نیست. اگر یک object تمام متغیر‌ها و توابع مورد نیاز یک اینترفیس را پیاده سازی کند به راحتی همانند روش explicit emplementation می‌توان از آن object استفاده کرد.  به این قابلیت Duck Typing  می‌گویند. مثال:
IPerson {
   firstName: string;
   lastName: string;
} 
class Person implements IPerson {
  constructor(public firstName: string, public lastName: string) {
  }
}

varpersonA: IPerson = newPerson('Masoud', 'Pakdel'); //expilict
varpersonB: IPerson = { firstName: 'Ashkan', lastName: 'Shahram'}; // duck typing
همان طور که می‌بینید object  دوم به نام personB تمام متغیر‌ها ی مورد نیاز اینترفیس IPerson را پیاده سازی کرده است در نتییجه کامپایلر همان رفتاری را که با object اول به نام personA دارد را با آن نیز خواهد داشت.

پیاده سازی چند اینترفیس به صورت همزمان
همانند دات نت که یک کلاس فقط می‌تواند از یک کلاس ارث ببرد ولی می‌تواند n  تا اینترفیس را پیاده سازی کند در TypeScript نیز چنین قوانینی وجود دارد. یعنی یک اینترفیس می‌تواند چندین اینترفیس دیگر را توسعه دهد(extend) و کلاسی که این اینترفیس را پیاده سازی می‌کند باید تمام توابع اینترفیس‌ها را پیاده سازی کند. مثال:
interface IMover {
 move() : void;
}

interface IShaker {
 shake() : void;
} 

interface IMoverShaker extends IMover, IShaker {
}
class MoverShaker implements IMoverShaker {
 move() {
 }
 shake() {
 }
}
*به کلمات کلیدی extends و implements و طریقه به کار گیری آن‌ها دقت کنید.

 instanceof

از instanceof زمانی استفاده می‌کنیم که قصد داشته باشیم که یک instance را با یک نوع مشخص مقایسه کنیم. اگر instance مربوطه از نوع مشخص باشد یا از این نوع ارث برده باشد مقدار true برگشت داده می‌شود در غیر این صورت مقدار false خواهد بود.
یک مثال:
var isLogger = logger instanceof Utilities.Logger; 
var isLogger = logger instanceof Utilities.AnnoyingLogger; 
var isLogger = logger instanceof Utilities.Formatter;
Method overriding
در TypeScript می‌توان مانند زبان‌های شی گرای دیگر Method overriding را پیاده سازی کرد. یعنی می‌توان متد‌های کلاس پایه را در کلاس مشتق شده تحریف کرد. با یک مثال به شرح این مورد خواهم پرداخت.
فرض کنید یک کلاس پایه به صورت زیر داریم:
class BaseEmployee
{   
    constructor (public fname: string,public lname: string) 
    {  
    }  
    sayInfo() 
    {  
       alert('this is base class method');
    }  
}
کلاس دیگری به نام Employee می‌سازیم که کلاس بالا را توسعه می‌دهد(یا به اصطلاح از کلاس بالا ارث می‌برد).
class Employee extends BaseEmployee
{  
   sayInfo() 
     {  
        alert('this is derived class method');
     }  
}  

window.onload = () =>  
{   
    var first: BaseEmployee= new Employee();     
    first.sayInfo();  
    var second: BaseEmployee = new BaseEmployee(); 
    second.sayInfo(); 
}
نکته مهم این است که دیگر خبری از کلمه کلیدی virtual برای مشخص کردن توابعی که قصد overriding آن‌ها را داریم نیست. تمام توابع که عمومی هستند را می‌توان override کرد.
*اگر در کلاس مشتق شده قصد داشته باشیم که به توابع و فیلد‌های کلاس پایه اشاره کنیم باید از کلمه کلیدی super استفاده کنیم.(معادل base در #C).
مثال:
class Animal {
    constructor (public name: string) {
    }
}

class Dog extends Animal {    
      constructor (public name: string, public age:number)
      {
        super(name);
      }

    sayHello() {
alert(super.name);
 } }
اگر به سازنده کلاس مشتق شده دقت کنید خواهید دید که پارامتر name را به سازنده کلاس پایه پاس دادیم: کد معادل در #C به صورت زیر است:
public class Dog : Animal 
{    
      public Dog (string name, int age):base(name)
      {
      }
}
در تابع sayHello نیز با استفاده از کلمه کلیدی super به فیلد name در کلاس پایه دسترسی خواهیم داشت.

*دقت کنید که مباحث مربوط به interface و private modifier و Type safety که پیش‌تر در مورد آن‌ها بحث شد، فقط در فایل‌های TypeScript و در هنگام کد نویسی و طراحی معنی دار هستند، زیرا بعد از کامپایل فایل‌های ts این مفاهیم در Javascript پشتیبانی نمی‌شوند در نتیجه هیچ مورد استفاده هم نخواهد داشت.

ادامه دارد...
مطالب
آموزش TypeScript #4
در پست‌های قبل با کلیات و primitive types در زبان TypeScript آشنا شدیم:

در این پست به مفاهیم شی گرایی در این زبان می‌پردازیم.

ماژول ها:
تعریف یک ماژول: برای تعریف یک ماژول باید از کلمه کلیدی module استفاده کنید. یک ماژول معادل یک ظرف است برای نگهداری کلاس‌ها و اینترفیس‌ها و سایر ماژول ها. کلاس‌ها و اینترفیس‌ها در TypeScript می‌توانند به صورت internal یا public باشند(به صورت پیش فرض internal است؛ یعنی فقط در همان ماژول قابل استفاده و فراخوانی است). هر چیزی که در داخل یک ماژول تعریف می‌شود محدوده آن در داخل آن ماژول خواهد بود. اگر قصد توسعه یک پروژه در مقیاس بزرگ را دارید می‌توانید همانند دات نت که در آن امکان تعریف فضای نام‌های تودرتو امکان پذیر است در TypeScript نیز، ماژول‌های تودرتو تعریف کنید.  برای مثال:
module MyModule1 {
    module  MyModule2 {
     }
}
اما به صورت معمول سعی می‌شود هر ماژول در یک فایل جداگانه تعریف شود. استفاده از چند ماژول در یک فایل به مرور، درک پروژه را سخت خواهد کرد و در هنگام توسعه امکان برخورد با مشکل وجود خواهد داشت. برای مثال اگر یک فایل به نام MyModule.ts داشته باشیم که یک ماژول به این نام را شامل شود بعد از کامپایل یک فایل به نام  MyModule.js ایجاد خواهد شد. 

کلاس ها:
برای تعریف یک کلاس می‌توانیم همانند دات نت از کلمه کلیدی class استفاده کنیم. بعد از تعریف کلاس می‌توانیم متغیر‌ها و توابع مورد نظر را در این کلاس قرار داده و تعریف کنیم.  
module Utilities {
   export class Logger {
      log(message: string): void{
       if(typeofwindow.console !== 'undefined') {
           window.console.log(message);
        }
      }
   }    
}
نکته مهم و جالب قسمت بالا کلمه export است. export معادل public در دات نت است و کلاس  logger را قابل دسترس در خارج ماژول Utilities خواهد کرد. اگر از export در هنگام تعریف کلاس استفاده نکنیم این کلاس فقط در سایر کلاس‌های تعریف شده در داخل همان ماژول قابل دسترس است.
تابع log  که در کلاس بالا تعریف کردیم به صورت پیش فرض public یا عمومی است و نیاز به استفاده export نیست.
برای استفاده از کلاس بالا باید این کلمه کلیدی new استفاده کنیم.  
window.onload = function() {
  varlogger = new Utilities.Logger();
  logger.log('Logger is loaded'); 
};
برای تعریف سازنده برای کلاس بالا باید از کلمه کلیدی constructor استفاده نماییم:
export class Logger{
constructor(private num: number) { 
}
با کمی دقت متوجه تعریف متغیر num به صورت private خواهید شد که برخلاف انتظار ما در زبان‌های دات نتی است. بر خلاف دات نت در زبان TypeScript، دسترسی به متغیر تعریف شده در سازنده با کمک اشاره گر this  در هر جای کلاس ممکن می‌باشد. در نتیجه نیازی به تعریف متغیر جدید و  پاس دادن مقادیر این متغیر‌ها به این فیلدها نمی‌باشد.
اگر به تابع log دقت کنید خواهید دید که یک پارامتر ورودی به نام message دارد که نوع آن string است. در ضمن Typescript از پارامتر‌های اختیاری( پارامتر با مقدار پیش فرض) نیز پشتیبانی می‌کند. مثال:

pad(num: number, len: number= 2, char: string= '0')
استفاده از پارامترهای Rest
منظور از پارامترهای Rest یعنی در هنگام فراخوانی توابع محدودیتی برای تعداد پارامتر‌ها نیست که معادل params در دات نت است. برای تعریف این گونه پارامترهاکافیست به جای params از ... استفاده نماییم.
function addManyNumbers(...numbers: number[]) {
  var sum = 0;
  for(var i = 0; i < numbers.length; i++) {
    sum += numbers[i];
 }
  returnsum;
}
var result = addManyNumbers(1,2,3,5,6,7,8,9);
تعریف توابع خصوصی
در TypeScript امکان توابع خصوصی با کلمه کلیدی private امکان پذیر است. همانند دات نت با استفاده از کلمه کلیدی private می‌توانیم کلاسی تعریف کنیم که فقط برای همان کلاس قابل دسترس باشد(به صورت پیش فرض توابع به صورت عمومی هستند).
module Utilities {
    Export class Logger {  
     log(message: string): void{
                 if(typeofwindow.console !== 'undefined') {   
                    window.console.log(this.getTimeStamp() + ' -'+ message);
                    window.console.log(this.getTimeStamp() + ' -'+ message); 
                }
        }
  private getTimeStamp(): string{
      var now = newDate();
      return now.getHours() + ':'+
      now.getMinutes() + ':'+
      now.getSeconds() + ':'+
      now.getMilliseconds();
  }
 }
}
از آن جا که تابع getTimeStamp به صورت خصوصی تعریف شده است در نتیجه امکان استفاده از آن در خارج کلاس وجود ندارد. اگر سعی بر استفاده این تابع داشته باشیم توسط کامپایلر با یک warning مواجه خواهیم شد.

یک نکته مهم این است که کلمه private فقط برای توابع و متغیر‌ها قابل استفاده است.

تعریف توابع static:

در TypeScript امکان تعریف توابع static وجود دارد. همانند دات نت باید از کلمه کلیدی static استفاده کنیم.

classFormatter {
static pad(num: number, len: number, char: string): string{
      var output = num.toString();
         while(output.length < len) {
         output = char + output;
      }
   returnoutput;
   }
  }
}
و استفاده از این تابع بدون وهله سازی از کلاس :
Formatter.pad(now.getSeconds(), 2, '0') +
Function Overload
همان گونه که در دات نت امکان overload کردن توابع میسر است در TypeScript هم این امکان وجود دارد.
static pad(num: number, len?: number, char?: string);
static pad(num: string, len?: number, char?: string);
static pad(num: any, len: number= 2, char: string= '0') {
 var output = num.toString();
 while(output.length < len) {
 output = char + output;
 }
 returnoutput;
}

ادامه دارد...
مطالب
مدیریت تغییرات در سیستم های مبتنی بر WCF
تشریح مسئله : در صورتی که بعد از انتشار برنامه؛ در نسخه بعدی مدل سمت سرور تغییر کرده باشد و امکان بروز رسانی مدل‌های سمت کلاینت وجود نداشته باشد برای حل این مسئله بهترین روش کدام است.
نکته : برای فهم بهتر مطالب آشنایی اولیه با مفاهیم WCF الزامی است.
ابتدا مدل زیر را در نظر بگیرید:
   [DataContract]
    public class Book 
    {
        [DataMember]
        public int Code { get; set; }

        [DataMember]
        public string Name { get; set; }             
    }
حالا یک سرویس برای دریافت و ارسال اطلاعات این مدل به کلاینت می‌نویسیم.
  [ServiceContract]
    public interface ISampleService
    {
        [OperationContract]
        IEnumerable<Book> GetAll();

        [OperationContract]
        void Save( Book book );
    }
و سرویسی که Contract بالا رو پیاده سازی کند.
public class SampleService : ISampleService
    {
        public List<Book> ListOfBook 
        {
            get; 
            private set; 
        }

        public SampleService()
        {
            ListOfBook = new List<Book>();
        }
        public IEnumerable<Book> GetAll()
        {
            ListOfBook.AddRange( new Book[] 
            {
                new Book(){Code=1 , Name="Book1"},
                new Book(){Code=2 , Name="Book2"},
            } );
            return ListOfBook;
        }

        public void Save( Book book )
        {
            ListOfBook.Add( book );
        }
    }
 متد GetAll برای ارسال اطلاعات به کلاینت و متد Save نیز برای دریافت اطلاعات از کلاینت.
حالا یک پروژه Console Application بسازید و از روش AddServiceReference سرویس مورد نظر را به Client اضافه کنید. برنامه را تست کنید. بدون هیچ مشکلی کار می‌کند.
حالا اگر در نسخه بعدی سیستم مجبور شویم به مدل Book یک خاصیت دیگر به نام Author را نیز اضافه کنیم و امکان Update کردن سرویس در سمت کلاینت وجود نداشته باشد چه اتفاقی خواهد افتاد.
به صورت زیر:
 [DataContract]
    public class Book 
    {
        [DataMember]
        public int Code { get; set; }
        [DataMember]
        public string Name { get; set; }

        [DataMember]
        public string Author { get; set; }
    }
به طور پیش فرض اگر در DataContract‌های سمت سرور و کلاینت اختلاف وجود داشته باشد این موارد نادیده گرفته می‌شوند. یعنی همیشه مقدار خاصیت Author برابر null خواهد بود.
نکته : برای Value Type‌ها مقادیر پیش فرض و برای Reference Type‌ها مقدار Null.
اگر برای DataMemberAttribute خاصیت IsRequired را برابر true کنیم از این پس برای هر درخواستی که مقدار Author  آن مقدار نداشته باشد یک Protocol Exception  پرتاب می‌شود. به صورت زیر:
[DataMember( IsRequired = true )]
public string Author { get; set; }
اما این همیشه راه حل مناسبی نیست.
روش دیگر این است که Desrialize کردن مدل را تغییر دهیم. بدین معنی که هر گاه مقدار Author برابر Null بود یک مقدار پیش فرض برای آن در نظر بگیریم. این کار با نوشتن یک متد و قراردادن OnDeserializingAttribute به راحتی امکان پذیر است. کلاس Book به صورت زیر تغییر می‌کند.
  [DataContract]
    public class Book
    {
        [DataMember]
        public int Code { get; set; }
        [DataMember]
        public string Name { get; set; }

        [DataMember( IsRequired = true )]
        public string Author { get; set; }

        [OnDeserializing]
        private void OnDeserializing( StreamingContext context )
        {
            if ( string.IsNullOrEmpty( Author ) )
            {
                Author = "Masoud Pakdel";
            }
        }
    }
حال اگر از سمت کلاینت کلاس Book دریافت شود که مقدار خاصیت Author آن برابر Null باشد توسط متد OnDeserializing مقدار پیش فرض به آن اعمال می‌شود.مثل تصویر زیر:

روش بعدی استفاده از اینترفیس IExtensibleDataObject  است. بعد از اینکه کلاس Book این اینترفیس را پیاده سازی کرد مشکل Versioning Round Trip حل می‌شود. به این صورت که سرویس یا کلاینتی که نسخه قدیمی را می‌شناسد اگر نسخه جدید را دریافت کند خصوصیاتی را که نمی‌شناسد مثل Author در خاصیت ExtensionData ذخیره می‌شود و هنگامی که کلاس Book برای سرویس یا کلاینتی که نسخه جدید را می‌شناسد DataContractSerializer اطلاعات مورد نظر را از خصوصیت ExtensionData بیرون می‌کشد و کلاس Book جدید را باز سازی می‌کند. بررسی کلاس ExtensionData توسط خود DataContractSreializer انجام می‌شود و نیاز به هیچ گونه ای کد نویسی ندارد.

[DataContract]
    public class Book : IExtensibleDataObject
    {
        [DataMember]
        public int Code { get; set; }
        [DataMember]
        public string Name { get; set; }

        [DataMember]
        public string Author { get; set; }
    
        public virtual ExtensionDataObject ExtensionData
        {
            get { return _extensionData; }
            set
            {
                _extensionData = value;
            }
        }
        private ExtensionDataObject _extensionData;
    }
اگر کد متد GetAll سمت سرور را به صورت زیر تغییر دهیم که خاصیت Author هم مقدار داشته باشد با استفاده از خاصیت ExtensionData کلاینت هم از این مقدار مطلع خواهد شد.
public IEnumerable<Book> GetAll()
        {
            ListOfBook.AddRange( new Book[] 
            {
                new Book(){Code=1 , Name="Book1", Author="Masoud Pakdel"},
                new Book(){Code=2 , Name="Book2" },
            } );
            return ListOfBook;
        }
کلاینت هم به صورت زیر :

همان طور که می‌بینید این نسخه از کلاینت هیچ گونه اطلاعی از وجود یک خاصیت به نام Author ندارد ولی از طریق ExtensionData متوجه می‌شود یک خاصیت به نام Author به مدل سمت سرور اضافه شده است.

اما در صورتی که قصد داشته باشیم که یک سرویس خاص از همان نسخه قدیمی کلاس Book استفاده کند و نیاز به نسخه جدید آن نداشته باشد می‌توانیم این کار را از طریق مقدار دهی True به خاصیت IgnoreExtensionDataObject  در ServiceBehaviorAttribute انجام داد. بدین شکل

 [ServiceBehavior( IgnoreExtensionDataObject = true )]
  public class SampleService : ISampleService
از این پس سرویس بالا از همان مدل Book بدون خاصیت Author استفاده می‌کند.

منابع :