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

این الگو به توسعه دهندگان این اجازه را میدهد که کتابخانه‌ها (libraries)، فریم ورک‌ها (frameworks) و ... را گسترش دهند.


مثال: 

class Visitor {
    visit(item){}
}

class BookVisitor extends Visitor {
    visit(book) {
        var cost=0; 
        if(book.getPrice() > 50) 
        { 
            cost = book.getPrice()*0.50 
        } 
        else{
            cost = book.getPrice()
        }     
        console.log("Book name: "+ book.getName() + "\n" + "ID: " + book.getID() + "\n" + "cost: "+ cost); 
        return cost; 
    }
}

class Book{
    constructor(id,name,price){
        this.id = id
        this.name = name
        this.price = price
    }
    getPrice(){
        return this.price
    }
    getName(){
        return this.name
    }
    getID(){
        return this.id
    }
    accept(visitor){
        return visitor.visit(this)
    }
}

var visitor = new BookVisitor()
var book1 = new Book("#1234","lordOftheRings",80)
book1.accept(visitor)

در مثال بالا ما یک کتابفروشی داریم. کلاس Book برای نشان دادن یک کتاب در فروشگاه استفاده شده‌است. این کلاس همانند زیر تعریف شده‌است: 
class Book{
    constructor(id,name,price){
        this.id = id
        this.name = name
        this.price = price
    }
    //code...
}

یک کتاب خصوصیات زیر را دارد: 
  • id
  • name
  • price

هم چنین شامل توابع زیر می‌باشد:
getPrice(){
    return this.price
}

getName(){
    return this.name
}

getID(){
    return this.id
}

متد getPrice ، قیمت را برگشت میدهد، getName ، نام را برگشت میدهد و getID، شناسه‌ی کتاب را برگشت میدهد.

اکنون کتابفروشی یک تخفیف را برای کتاب‌هایی که هزینه‌ی آن‌ها بیشتر از 50 دلار است، معرفی می‌کند. در ادامه، می‌خواهیم یک عملیات دیگر را انجام دهیم و تخفیف را بر روی آن‌ها پیاده سازی کنیم. در اینجا از الگوی visitor استفاده خواهیم کرد. ما یک Visitor را معرفی می‌کنیم که کتابها را بازدید خواهد کرد و قیمت آن‌ها را به‌روزرسانی می‌کند. بنابراین شیء‌های کتاب باید تابعی داشته باشند که اجازه دهد visitor، آنها را بازدید (visit) کند و عملیات مد نظر را بر روی آن‌ها انجام دهد. برای این منظور، یک متد به نام accept  در کلاس Book  تعریف کرده‌ایم:
 
accept(visitor){
    return visitor.visit(this)
}

متد accept  یک شیء visitor را به عنوان یک آرگومان دریافت می‌کند و به آن اجازه میدهد که با فراخوانی کردن تابع visit خودش، کتاب جاری را بازدید (visit) کند (this اشاره به کتاب جاری دارد) .

اکنون اجازه دهید نگاهی به کلاس Visitor  داشته باشیم: 
class Visitor {
   visit(item){}
}

این کلاس، یک تابع به نام visit دارد و itemی را که می‌خواهد بازدید (visit ) کند، به عنوان پارامتر دریافت می‌کند. در این سناریو، می‌خواهیم که کتاب‌ها را بازدید (visit ) کنیم. از این رو، در ابتدا یک کلاس را به نام BookVisitor تعریف می‌کنیم که کلاس Visitor را extend می‌کند: 

class BookVisitor extends Visitor {
   visit(book) {
      var cost=0; 
      if(book.getPrice() > 50) 
      { 
         cost = book.getPrice()*0.50 
      } 
      else{
         cost = book.getPrice()
      }     
      console.log("Book name: "+ book.getName() + "\n" + "ID: " + book.getID() + "\n" + "cost: "+ cost); 
      return cost; 
   }
}

تابع visit، قیمت کتابی را که دارد بازدید می‌کند، بررسی می‌کند. اگر بزرگتر از 50 باشد، 50 درصد تخفیف را بر روی آن اعمال می‌کند؛ در غیر این صورت، قیمت به حالت قبلی خودش باقی می‌ماند. 

چه زمانی از این الگو استفاده کنیم:

  1. زمانیکه نیاز است عملیاتی مشابه، بر روی شیء‌های متفاوتی از یک data structure  انجام شود. 
  2. زمانیکه نیاز است عملیاتی خاص، بر روی شیء‌های متفاوتی از data structure انجام شود. 
  3. زمانیکه می‌خواهید توسعه پذیری را برای کتابخانه‌ها (libraries) یا فریم ورک‌ها (frameworks) اضافه کنید.
مطالب
مدیریت حالت در برنامه‌های Blazor توسط الگوی Observer - قسمت اول
نیاز به مدیریت حالت در برنامه‌های Blazor

«حالت» یا state، شیءای است، حاوی اطلاعاتی که برنامه با آن سر و کار دارد. بنابراین مدیریت حالت، روشی است برای ردیابی و مدیریت داده‌های مورد استفاده‌ی در برنامه و تقریبا تمام برنامه‌ها، به نحوی به آن نیاز دارند. هر کامپوننت در Blazor، دارای state خاص خودش است و این state از سایر کامپوننت‌ها کاملا مستقل و ایزوله‌است. این مورد با بزرگ‌تر شدن برنامه و برقراری ارتباط بین کامپوننت‌ها، مشکل ایجاد می‌کند. برای مثال اگر قرار است در منوی بالای سایت، تعداد محصولات موجود در سبد خرید یک شخص را نمایش دهیم، این تعداد، حاصل تعامل او با چندین کامپوننت مجزا خواهد بود که این‌ها الزاما در یک سلسه مراتب هم قرار نمی‌گیرند و به سادگی نمی‌توان اطلاعات را به صورت آبشاری در بین آن‌ها به اشتراک گذاشت. به همین جهت نیاز به روشی برای مدیریت حالت و به اشتراک گذاری آن در بین کامپوننت‌های مختلف برنامه وجود دارد و خوشبختانه چون Blazor به همراه یک سیستم تزریق وابستگی‌های توکار است، پیاده سازی یک چنین مدیریت کننده‌ای، ساده‌است.


استفاده از الگوی Observer جهت مدیریت حالت برنامه‌های Blazor


زمانیکه همانند تصویر فوق با یک کامپوننت کار می‌کنیم، کاربر همواره کارش از تعامل با یک View آغاز می‌شود. این تعامل سبب صدور رخ‌دادهایی می‌شود که این رخ‌دادها، حالت و state کامپوننت را تغییر می‌دهند. تغییر حالت کامپوننت نیز بلافاصله سبب به‌روز رسانی View می‌شود. در این مثال، حالت کامپوننت، داخل همان کامپوننت نگه‌داری می‌شود؛ مانند فیلدهایی که در قسمت code@ یک کامپوننت Blazor تعریف می‌کنیم و محدود به همان کامپوننت هستند.
با بزرگتر شدن برنامه، زمانی خواهد رسید که نیاز است حالت یک کامپوننت را با کامپوننت‌های دیگر به اشتراک گذاشت. در این حالت باید این state را از داخل کامپوننت مدنظر استخراج کرد و در جائی دیگر قرار داد که عموما به آن state store گفته می‌شود:


در تصویر فوق، در بالای آن یک state store را داریم که محل نگه‌داری و ذخیره سازی حالت اشتراکی بین کامپوننت‌ها است. سپس برای نمونه دو کامپوننت دیگر را داریم که رابطه‌ی بین آن‌ها، همان رابطه‌ی مثلثی است که در تصویر اول این مطلب مشاهده کردیم. برای مثال در اثر تعامل کاربری با View کامپوننت 1، رخ‌دادی صادر خواهد شد. مدیریت این رخ‌داد، سبب تغییر state خواهد شد، اما اینبار این state دیگر داخل کامپوننت 1 قرار ندارد؛ بلکه داخل state store است و این store پس از آگاه شدن از تغییر وضعیت خود، دو کامپوننتی را که از آن تغدیه می‌کنند، جهت به روز رسانی Viewهایشان، مطلع می‌کند. همین چرخه در مورد کامپوننت 2 نیز برقرار است. اگر تعاملی با آن صورت گیرد، در نهایت اثر آن به هر دو کامپوننت متصل به state store اشتراکی، اطلاع رسانی می‌شود تا Viewهای هر دوی آن‌ها به روز رسانی شوند. الگویی را که در اینجا مشاهده می‌کنید، در اصل یک الگوی Observer است:


در الگوی مشاهده‌گر، یک Subject را داریم که تعداد زیادی Observer، مشترک آن هستند. در این مثال ما، Subject، همان State Store است و Observerها دقیقا همان کامپوننت‌های مشترک به آن. Observerها به تغییرات Subject گوش فرا داده و بلافاصله بر اساس آن واکنش مناسبی را نشان می‌دهند.


پیاده سازی الگوی Observer جهت مدیریت حالت برنامه‌های Blazor

زمانیکه یک برنامه‌ی متداول Blazor را توسط قالب پیش‌فرض آن ایجاد می‌کنیم، به همراه یک کامپوننت Counter است:
@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}
در این مثال فیلد currentCount، همان حالت کامپوننت جاری است که تنها مختص به آن است. اکنون می‌خواهیم این حالت را با کامپوننتی که منوی سمت چپ صفحه را تشکیل می‌دهد (یعنی Client\Shared\NavMenu.razor) به اشتراک گذاشته و با کلیک بر روی دکمه‌ی این شمارشگر، عدد حاصل را علاوه بر View این کامپوننت، در کنار برچسب منوی آن نیز نمایش دهیم.
بنابراین در قدم اول نیاز به یک State Store اشتراکی را داریم که بتوانیم توسط آن، مقدار جاری currentCount را ذخیره کرده و سپس تغییرات آن‌را جهت به روز رسانی دو View (در کامپوننت‌های Counter و NavMenu)، به مشترکین آن اطلاع رسانی کنیم. به همین جهت ابتدا پوشه‌ی جدید Stores را در ریشه‌ی پروژه‌ی Blazor ایجاد می‌کنیم. نام این پوشه، از این جهت یک اسم جمع است که یک برنامه بنابر نیاز خودش می‌تواند چندین State Store را داشته باشد. سپس داخل این پوشه، پوشه‌ی دیگری را به نام CounterStore، ایجاد می‌کنیم.
در اینجا در ابتدا شیء حالت مدنظر را ایجاد می‌کنیم که برای نمونه بر اساس نیاز برنامه و این مثال، از مقدار نهایی کلیک بر روی دکمه‌ی شمارشگر تشکیل می‌شود:
namespace BlazorStateManagement.Stores.CounterStore
{
    public class CounterState
    {
        public int Count { get; set; }
    }
}
از این حالت، در مخزن حالت جدید زیر استفاده خواهیم کرد:
using System;

namespace BlazorStateManagement.Stores.CounterStore
{
    public interface ICounterStore
    {
        void DecrementCount();
        void IncrementCount();
        CounterState GetState();

        void AddStateChangeListener(Action listener);
        void BroadcastStateChange();
        void RemoveStateChangeListener(Action listener);
    }
}

using System;
namespace BlazorStateManagement.Stores.CounterStore
{
    public class CounterStore : ICounterStore
    {
        private readonly CounterState _state = new();
        private Action _listeners;

        public CounterState GetState()
        {
            return _state;
        }

        public void IncrementCount()
        {
            _state.Count++;
            BroadcastStateChange();
        }

        public void DecrementCount()
        {
            _state.Count--;
            BroadcastStateChange();
        }

        public void AddStateChangeListener(Action listener)
        {
            _listeners += listener;
        }

        public void RemoveStateChangeListener(Action listener)
        {
            _listeners -= listener;
        }

        public void BroadcastStateChange()
        {
            _listeners.Invoke();
        }
    }
}
توضیحات:
- مخزن حالت پیاده سازی شده‌ی بر اساس الگوی مشاهده‌گر، نیاز دارد تا بتواند لیست مشاهده‌گرها را ثبت کند. به همین جهت به همراه متدهای AddStateChangeListener جهت ثبت یک مشاهده‌گر جدید و RemoveStateChangeListener، جهت حذف مشاهده‌گری از لیست موجود است.
- همچنین الگوی مشاهده‌گر باید بتواند تغییرات صورت گرفته‌ی در حالتی را که نگه‌داری می‌کند (CounterState در اینجا)، به مشترکین خود اطلاع رسانی کند. اینکار را توسط متد BroadcastStateChange انجام می‌دهد. هر زمانیکه این متد فراخوانی شود، Actionهایی که به صورت پارامتر به متد AddStateChangeListener ارسال شده‌اند، به صورت خودکار اجرا خواهند شد. این کار سبب می‌شود تا بتوان منطق خاصی را مانند به روز رسانی UI، در سمت کامپوننت‌های مشترک به این مخزن، پیاده سازی کرد.
- در اینجا همچنین متدهایی برای افزایش و کاهش مقدار Count را نیز به همراه اطلاع رسانی به مشترکین، مشاهده می‌کنید.

پس از این تعریف نیاز است سرویس Store ایجاد شده را به برنامه معرفی کرد:
namespace BlazorStateManagement.Client
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            //...
            builder.Services.AddScoped<ICounterStore, CounterStore>();
            //...
        }
    }
}
با توجه به اینکه در هر دو حالت Blazor Server و همچنین Blazor Wasm، طول عمر Scoped، دقیقا مانند حالت Singleton عمل می‌کند، سرویس ICounterStore و حالت نگهداری شده‌ی توسط آن، تا پایان عمر برنامه (بسته شدن مرورگر یا ریفرش کامل صفحه‌ی جاری)، در حافظه باقی مانده و وهله سازی مجدد نخواهد شد. به همین جهت تزریق آن در کامپوننت‌های مختلف برنامه، دقیقا حالت مخزن داده‌ی اشتراکی را پیدا خواهد کرد. این مورد یکی از مزیت‌های کار با Blazor است که به همراه یک سیستم تزریق وابستگی‌های توکار است.


تغییر کامپوننت‌های برنامه برای استفاده از سرویس ICounterStore

پس از معرفی سرویس ICounterStore به سیستم تزریق وابستگی‌های برنامه، جهت سهولت استفاده‌ی از آن، در ابتدا فضای نام آن‌را به فایل سراسری Client\_Imports.razor اضافه می‌کنیم:
@using BlazorStateManagement.Stores.CounterStore
سپس تغییرات کامپوننت شمارشگر، جهت استفاده‌ی از سرویس ICounterStore، به صورت زیر خواهند بود:
@page "/counter"
@implements IDisposable

@inject ICounterStore CounterStore

<h1>Counter</h1>

<p>Current count: @CounterStore.GetState().Count</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    protected override void OnInitialized()
    {
        base.OnInitialized();
        CounterStore.AddStateChangeListener(UpdateView);
    }

    private void IncrementCount()
    {
        CounterStore.IncrementCount();
    }

    private void UpdateView()
    {
        StateHasChanged();
    }

    public void Dispose()
    {
        CounterStore.RemoveStateChangeListener(UpdateView);
    }
}
توضیحات:
- در اینجا در ابتدا سرویس ICounterStore، به کامپوننت تزریق شده‌است.
- سپس در متد رویدادگران آغازین OnInitialized، با استفاده از متد AddStateChangeListener، مشترک سرویس مخزن حالت شمارشگر شده‌ایم.
- همواره جهت پاکسازی کد و عدم اشتراک بیش از اندازه‌ی به یک مخزن حالت، نیاز است در پایان کار یک کامپوننت، با پیاده سازی implements IDisposable@، کار حذف اشتراک را انجام دهیم. در غیراینصورت هربار که کامپوننت بارگذاری می‌شود، یک اشتراک جدید از این کامپوننت، به مخزن حالتی که طول عمر Singleton دارد، اضافه خواهد شد که نشانی از نشتی حافظه‌است.
- دو قسمت دیگر را هم تغییر داده‌ایم. اینبار با استفاده از متد ()GetState، این Count اشتراکی را نمایش می‌دهیم و همچنین عمل به روز رسانی State را هم توسط متد IncrementCount انجام داده‌ایم.


در ادامه کامپوننت Client\Shared\NavMenu.razor را نیز جهت نمایش مقدار جاری Count، به صورت زیر به روز رسانی می‌کنیم:
@inject ICounterStore CounterStore

<li class="nav-item px-3">
   <NavLink class="nav-link" href="counter">
      <span class="oi oi-plus" aria-hidden="true"></span> Counter: @CounterStore.GetState().Count
   </NavLink>
</li>

@code {
    protected override void OnInitialized()
    {
        base.OnInitialized();
        CounterStore.AddStateChangeListener(() => StateHasChanged());
    }

    // ...
}
توضیحات:
- در اینجا نیز در ابتدا سرویس ICounterStore، به کامپوننت تزریق شده‌است.
- سپس در متد رویدادگران آغازین OnInitialized، با استفاده از متد AddStateChangeListener، مشترک سرویس مخزن حالت شمارشگر شده‌ایم و هربار که متد BroadcastStateChange ای توسط یکی از کامپوننت‌های متصل به مخزن حالت فراخوانی می‌شود (برای مثال در انتهای متد IncrementCount خود سرویس)، سبب اجرای Action آن که در اینجا StateHasChanged است، خواهد شد. فراخوانی StateHasChanged، کار اطلاع رسانی به UI، جهت رندر مجدد را انجام می‌دهد. به این ترتیب مقدار جدید Count توسط CounterStore.GetState().Count@ در منو نیز ظاهر خواهد شد:




کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: BlazorStateManagement.zip
مطالب
مدیریت حالت در برنامه‌های Blazor توسط الگوی Observer - قسمت دوم
در قسمت قبل، روشی را بر اساس الگوی Observer، برای به اشتراک گذاری حالت و مدیریت سراسری آن، بررسی کردیم. در این روش می‌توان چندین مخزن حالت را نیز داشت؛ اما هر کدام مستقل از هم عمل می‌کنند. برای تکمیل آن فرض کنید قرار است عمل افزودن مقدار یک شمارشگر، در دو مخزن حالت متفاوت و مجزای از هم، در هر کدام سبب بروز تغییر حالتی خاص شود که در این مطلب روش مدیریت آن‌را بررسی خواهیم کرد.


نیاز به یک Dispatcher برای تعامل با بیش از یک مخزن حالت


در اینجا برای نمونه دو مخزن حالت تعریف شده‌اند؛ اما روش تعامل با این مخازن حالت، دیگر مانند قبل نیست. برای نمونه در اثر تعامل یک کاربر با View ای خاص، رخدادی صادر شده و اینبار مدیریت این رخداد توسط یک Action (که عموما یک پیام رشته‌ای است)، به Dispatcher مرکزی ارسال می‌شود (و نه مستقیما به مخزن حالت خاصی). اکنون این Dispatcher، اکشن رسیده را به مخازن کد مشترک به آن ارسال می‌کند تا عمل متناسب با آن اکشن درخواستی را انجام دهند. مابقی آن همانند قبل است که پس از تغییر حالت در هر کدام از مخازن حالت، کار به روز رسانی UI، در کامپوننت‌های مشترک صورت خواهد گرفت. بدیهی است در اینجا مخازن حالت، مجاز به صرفنظر کردن از یک اکشن خاص هستند و الزامی به پیاده سازی آن ندارند. هدف اصلی این است که اگر اکشنی قرار بود در تمام مخازن حالت پیاده سازی شود و حالت‌های آن‌ها را تغییر دهد، روشی را برای مدیریت آن داشته باشیم.
بنابراین اگر به این الگوی جدید دقت کنید، چیزی نیست بجز یک الگوی Observer دو سطحی:
الف) Dispatcher ای (Subject) که مشترک‌هایی را مانند مخازن حالت دارد (Observers).
ب) مخازن حالتی (Subjects) که مشترک‌هایی را مانند کامپوننت‌ها دارند (Observers).

اگر پیشتر با React کار کرده باشید، این الگو را تحت عناوینی مانند Flux و یا Redux می‌شناسید و در اینجا می‌خواهیم پیاده سازی #C آن‌را بررسی کنیم:


در الگوی Flux، در اثر تعامل یک کاربر با کامپوننتی، اکشنی به سمت یک Dispatcher ارسال می‌شود. سپس Dispatcher این اکشن را به مخزن حالتی جهت مدیریت آن ارسال می‌کند که در نهایت سبب تغییر حالت آن شده و به روز رسانی UI را در پی خواهد داشت.


پیاده سازی یک Dispatcher برای تعامل با بیش از یک مخزن حالت

پیش از هر کاری نیاز است قالب اکشن‌های ارسالی را که قرار است توسط مخازن حالت مورد پردازش قرار گیرند، مشخص کنیم:
namespace BlazorStateManagement.Stores
{
    public interface IAction
    {
        public string Name { get; }
    }
}
عموما هر اکشنی با نام و یا پیامی مشخص می‌شود. بر این اساس می‌توان اکشن افزودن و یا کاهش مقادیر شمارشگر را به صورت زیر تعریف کرد:
namespace BlazorStateManagement.Stores.CounterStore
{
    public class IncrementAction : IAction
    {
        public const string Increment = nameof(Increment);

        public string Name { get; } = Increment;
    }

    public class DecrementAction : IAction
    {
        public const string Decrement = nameof(Decrement);

        public string Name { get; } = Decrement;
    }
}
مزیت تعریف و استفاده از یک کلاس در اینجا این است که اگر نیاز بود به همراه اکشنی، اطلاعات اضافه‌تری نیز به سمت مخازن کد ارسال شوند، می‌توان آن‌ها را داخل هر کدام از کلاس‌ها، بسته به نیاز برنامه تعریف کرد و صرفا محدود به Name و یا یک مقدار رشته‌ای معرف آن، نخواهند بود.

پس از تعریف ساختار یک اکشن، اکنون نوبت به پیاده سازی راه حلی برای ارسال آن به تمام مخازن حالت برنامه است:
using System;

namespace BlazorStateManagement.Stores
{
    public interface IActionDispatcher
    {
        void Dispatch(IAction action);
        void Subscribe(Action<IAction> actionHandler);
        void Unsubscribe(Action<IAction> actionHandler);
    }

    public class ActionDispatcher : IActionDispatcher
    {
        private Action<IAction> _actionHandlers;

        public void Subscribe(Action<IAction> actionHandler) => _actionHandlers += actionHandler;

        public void Unsubscribe(Action<IAction> actionHandler) => _actionHandlers -= actionHandler;

        public void Dispatch(IAction action) => _actionHandlers?.Invoke(action);
    }
}
پیاده سازی ActionDispatcher ای را که ملاحظه می‌کنید، دقیقا مشابه CounterStore قسمت قبل است و در اینجا توسط متد Subscribe، مخازن حالت برنامه مشترک آن شده و یا توسط متد Unsubscribe، قطع اشتراک می‌کنند. همچنین متد Dispatch نیز شبیه به متد BroadcastStateChange قسمت قبل عمل می‌کند و سبب می‌شود تا اکشن ارسالی به آن، به تمام مشترکین این سرویس، ارسال شود.
این سرویس را نیز با طول عمر Scoped به سیستم تزریق وابستگی‌های برنامه معرفی می‌کنیم که سبب می‌شود تا پایان عمر برنامه (بسته شدن مرورگر یا ریفرش کامل صفحه‌ی جاری)، در حافظه باقی مانده و وهله سازی مجدد نشود. به همین جهت تزریق آن در مخازن حالت مختلف برنامه، دقیقا حالت یک Dispatcher اشتراکی را پیدا خواهد کرد.
namespace BlazorStateManagement.Client
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            // ...
            builder.Services.AddScoped<IActionDispatcher, ActionDispatcher>();
            // ...
        }
    }
}


استفاده از IActionDispatcher در مخازن حالت برنامه

در ادامه می‌خواهیم مخازن حالت برنامه را تحت کنترل سرویس IActionDispatcher قرار دهیم تا کاربر بتواند اکشنی را به Dispatcher ارسال کند و سپس Dispatcher این درخواست را به تمام مخازن حالت موجود، جهت بروز واکنشی (در صورت نیاز)، اطلاعات رسانی نماید.
برای این منظور سرویس ICounterStore قسمت قبل ، به صورت زیر تغییر می‌کند که اینترفیس IDisposable را پیاده سازی کرده و همچنین دیگر به همراه متدهای عمومی افزایش و یا کاهش مقدار نیست:
using System;

namespace BlazorStateManagement.Stores.CounterStore
{
    public interface ICounterStore : IDisposable
    {
        CounterState State { get; }

        void AddStateChangeListener(Action listener);
        void BroadcastStateChange();
        void RemoveStateChangeListener(Action listener);
    }
}
بر این اساس، پیاده سازی CounterStore به صورت زیر تغییر خواهد کرد:
using System;

namespace BlazorStateManagement.Stores.CounterStore
{
    public class CounterStore : ICounterStore
    {
        private readonly CounterState _state = new();
        private bool _isDisposed;
        private Action _listeners;
        private readonly IActionDispatcher _actionDispatcher;

        public CounterStore(IActionDispatcher actionDispatcher)
        {
            _actionDispatcher = actionDispatcher ?? throw new ArgumentNullException(nameof(actionDispatcher));
            _actionDispatcher.Subscribe(HandleActions);
        }

        private void HandleActions(IAction action)
        {
            switch (action)
            {
                case IncrementAction:
                    IncrementCount();
                    break;
                case DecrementAction:
                    DecrementCount();
                    break;
            }
        }

        public CounterState State => _state;

        private void IncrementCount()
        {
            _state.Count++;
            BroadcastStateChange();
        }

        private void DecrementCount()
        {
            _state.Count--;
            BroadcastStateChange();
        }

        public void AddStateChangeListener(Action listener) => _listeners += listener;

        public void RemoveStateChangeListener(Action listener) => _listeners -= listener;

        public void BroadcastStateChange() => _listeners.Invoke();

        public void Dispose()
        {
            Dispose(disposing: true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            if (!_isDisposed)
            {
                try
                {
                    if (disposing)
                    {
                        _actionDispatcher.Unsubscribe(HandleActions);
                    }
                }
                finally
                {
                    _isDisposed = true;
                }
            }
        }
    }
}
توضیحات:
- با توجه به اینکه CounterStore یک سرویس ثبت شده‌ی در سیستم است، می‌تواند از مزیت تزریق سایر سرویس‌ها در سازنده‌ی خودش بهره‌مند شود؛ مانند تزریق سرویس جدید IActionDispatcher.
- پس از تزریق سرویس جدید IActionDispatcher، متدهای Subscribe آن‌را در سازنده‌ی کلاس و Unsubscribe آن‌را در حین Dispose سرویس، فراخوانی می‌کنیم. البته فراخوانی و یا پیاده سازی Unsubscribe و Dispose در اینجا غیرضروری است؛ چون طول عمر این کلاس با طول عمر برنامه یکی است.
- بر اساس این الگوی جدید، هر اکشنی که به سمت Dispatcher مرکزی ارسال می‌شود، در نهایت به متد HandleActions یکی از مخازن حالت تعریف شده، خواهد رسید:
        private void HandleActions(IAction action)
        {
            switch (action)
            {
                case IncrementAction:
                    IncrementCount();
                    break;
                case DecrementAction:
                    DecrementCount();
                    break;
            }
        }
در اینجا می‌توان با استفاده از patterns matching، بر اساس نوع اکشن مدنظر، عملیات خاصی را انجام داد. فقط در اینجا دیگر متدهای IncrementCount و DecrementCount، عمومی نیستند. به همین جهت باید به کامپوننت شمارشگر مراجعه کرد و تعریف قبلی:
@inject ICounterStore CounterStore

@code {

    private void IncrementCount()
    {
        CounterStore.IncrementCount();
    }
را به صورت زیر تغییر داد:
- ابتدا در انتهای فایل Client\_Imports.razor، فضای نام سرویس جدید IActionDispatcher را اضافه می‌کنیم:
@using BlazorStateManagement.Stores
- سپس از آن جهت ارسال IncrementAction به مخازن حالت برنامه استفاده خواهیم کرد:
// ...
@inject IActionDispatcher ActionDispatcher


@code {

    private void IncrementCount()
    {
        ActionDispatcher.Dispatch(new IncrementAction());
    }
با این تغییر جدید، هربار که بر روی دکمه‌ی افزایش مقدار شمارشگر، کلیک می‌شود، در آخر یک IncrementAction به تمام مخازن حالت موجود در برنامه ارسال خواهد شد و آن‌ها بر اساس نیازشان تصمیم خواهند گرفت که آیا به آن واکنش نشان دهند یا خیر.

کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: BlazorStateManagement-Part-2.zip
مطالب
مدیریت پیشرفته‌ی حالت در React با Redux و Mobx - قسمت اول - Redux چیست؟
Redux و Mobx، کتابخانه‌های کمکی هستند برای مدیریت حالت برنامه‌های پیچیده‌ی React. هرچند React به صورت توکار به همراه امکانات مدیریت حالت است، اما این کتابخانه‌ها مزایای ویژه‌ای را به آن اضافه می‌کنند. در این سری ابتدا کتابخانه‌ی Redux را به صورت خالص و مجزای از React بررسی می‌کنیم. از این کتابخانه در برنامه‌های Angular و Ember هم می‌توان استفاده کرد و به صورت اختصاصی برای React طراحی نشده‌است. سپس آن‌را به برنامه‌های React متصل می‌کنیم. در آخر کتابخانه‌ی محبوب دیگری را به نام Mobx بررسی می‌کنیم که برای مدیریت حالت، اصول برنامه نویسی شیءگرا و همچنین Reactive را با هم ترکیب می‌کند و این روزها در برنامه‌های React، بیشتر از Redux مورد استفاده قرار می‌گیرد.


چرا به ابزارهای مدیریت حالت نیاز داریم؟

به محض رد شدن از مرز پیاده سازی امکانات اولیه‌ی یک برنامه، نیاز به ابزارهای مدیریت حالت نمایان می‌شوند؛ خصوصا زمانیکه نیاز است با اطلاعات قابل توجهی سر و کار داشت. مهم‌ترین دلیل استفاده‌ی از یک ابزار مدیریت حالت، مدیریت منطق تجاری برنامه است. منطق نمایشی برنامه مرتبط است به نحوه‌ی نمایش اجزای آن در صفحه؛ مانند نمایش یک صفحه‌ی مودال، تغییر رنگ عناصر با عبور کرسر ماوس از روی آن‌ها و در کل منطقی که مرتبط و یا وابسته‌ی به هدف اصلی برنامه نیست. از سوی دیگر منطق تجاری برنامه مرتبط است با مدیریت، تغییر و ذخیره سازی اشیاء تجاری مورد نیاز آن؛ مانند اطلاعات حساب کاربری شخص و دریافت اطلاعات برنامه از یک API که مختص به برنامه‌ی خاص ما است و به همین دلیل نیاز به ابزاری برای مدیریت بهینه‌ی آن وجود دارد. برای مثال اینکه در کجا باید منطق تجاری و نمایشی را به هم متصل کرد، می‌تواند چالش بر انگیر باشد. چگونه باید اطلاعات کاربر را ذخیره کرد؟ چگونه React باید متوجه شود که اطلاعات ما تغییر کرده‌است و در نتیجه‌ی آن کامپوننتی را مجددا رندر کند؟ یک ابزار مدیریت حالت، تمام این مسایل را به نحو یک‌دستی در سراسر برنامه، مدیریت می‌کند.
اگر از یک ابزار مدیریت حالت استفاده نکنیم، مجبور خواهیم شد تمام اطلاعات منطق تجاری را در داخل state کامپوننت‌ها ذخیره کنیم که توصیه نمی‌شود؛ چون مقیاس پذیر نیست. برای مثال فرض کنید قرار است تمام اطلاعات state را داخل یک کامپوننت ذخیره کنیم. هر زمانیکه بخواهیم این state را از طریق یک کامپوننت فرزند تغییر دهیم، نیاز خواهد بود این اطلاعات را به والد آن کامپوننت ارسال کنیم که اگر از تعداد زیادی کامپوننت تو در تو تشکیل شده باشد، زمانبر و به همراه کدهای تکراری زیادی خواهد بود. همچنین اینکار سبب رندر مجدد کل برنامه با هر تغییری در state آن می‌شود که غیرضروری بوده و کارآیی برنامه را کاهش می‌دهد. به علاوه در این بین مشخص نیست هر قسمت از state، از کدام کامپوننت تامین شده‌است. به همین جهت نیاز به روشی برای مدیریت حالت در بین کامپوننت‌های برنامه وجود دارد.


داشتن تنها یک محل برای ذخیره سازی state در برنامه

همانطور که در قسمت 8 ترکیب کامپوننت‌ها در سری React 16x بررسی کردیم، هر کامپوننت در React، دارای state خاص خودش است و این state از سایر کامپوننت‌ها کاملا مستقل و ایزوله‌است. این مورد با بزرگ‌تر شدن برنامه و برقراری ارتباط بین کامپوننت‌ها، مشکل ایجاد می‌کند. برای مثال اگر بخواهیم دکمه‌ای را در صفحه قرار داده و توسط این دکمه درخواست صفر شدن مقدار هر کدام از شمارشگرها را صادر کنیم، با صفر کردن value هر کدام از این کامپوننت‌ها، اتفاقی رخ نمی‌دهد. چون state محلی این کامپوننت‌ها، با سایر اجزای صفحه به اشتراک گذاشته نمی‌شود و باید آن‌را تبدیل به یک controlled component کرد، بطوریکه دارای local state خاص خودش نیست و تمام داده‌های دریافتی را از طریق this.props دریافت می‌کند و هر زمانیکه قرار است داده‌ای تغییر کند، رخ‌دادی را به والد خود صادر می‌کند. بنابراین این کامپوننت به طور کامل توسط والد آن کنترل می‌شود. تازه این روش در مورد کامپوننت‌هایی صدق می‌کند که رابطه‌ی والد و فرزندی بین آن‌ها وجود دارد. اگر چنین رابطه‌ای وجود نداشت، باید state را به یک سطح بالاتر انتقال داد. برای مثال باید state کامپوننت Counters را به والد آن که کامپوننت App است، منتقل کرد. پس از آن چون کامپوننت‌های ما، از کامپوننت App مشتق می‌شوند، اکنون می‌توان این state را به تمام فرزندان App توسط props منتقل کرد و به اشتراک گذاشت. این مورد هم مانند مثال انتقال اطلاعات کاربر لاگین شده‌ی به سیستم، به تمام زیر قسمت‌های برنامه، نیاز به ارسال اطلاعات از طریق props یک کامپوننت، به کامپوننت بعدی را دارد و به همین ترتیب برای مابقی که به props drilling مشهور است و روش پسندیده‌ای نیست.


Redux چیست؟ ذخیره سازی کل درخت state یک برنامه، در یک محل. به این ترتیب به یک شیء جاوا اسکریپتی بزرگ خواهیم رسید که در برگیرنده‌ی تمام state برنامه‌است. یکی از مزایای آن امکان serialize و deserialize کل این شیء، به سادگی است. برای مثال توسط متد JSON.stringify می‌توان آن‌را در جائی ذخیره کرد و سپس آن‌را به صورت یک شیء جاو اسکریپتی در زمانی دیگر بازیابی کرد. یکی از مزایای آن، امکان بازیابی دقیق شرایط کاربری است که دچار مشکل شده‌است و سپس دیباگ و رفع مشکل او، در زمانی دیگر.


تاریخچه‌ای از سیستم‌های مدیریت حالت

همه چیز با AngularJS 1x شروع شد که از data binding دو طرفه پشتیبانی می‌کرد. هرچند این روش برای همگام نگه داشتن View و مدل برنامه، مفید است، اما در Viewهای پیچیده، برنامه را کند می‌کند. در همین زمان فیس‌بوک، روش مدیریت حالتی را به نام Flux ارائه داد که از data binding یک طرفه پشتیبانی می‌کرد. به این معنا که در این روش، همواره اطلاعات از View به مدل، جریان پیدا می‌کند. کار کردن با آن ساده‌است؛ چون نیازی نیست حدس زده شود که اکنون جریان اطلاعات از کدام سمت است. اما مشکل آن عدم هماهنگی model و view، در بعضی از حالات است. Flux از این جهت به وجود آمد که مدیریت حالت در برنامه‌های React آن زمان، پیچیده بود و مقیاس پذیری کمی داشت (پیش از ارائه‌ی Context و Hooks). در کل Flux صرفا یکسری الگوی مدیریت حالت را بیان می‌کند و یک کتابخانه‌ی مجزا نیست. بر مبنای این الگوها و قراردادها، می‌توان کتابخانه‌های مختلفی را ایجاد کرد. از این رو در سال 2015، کتابخانه‌های زیادی مانند Reflux, Flummox, MartyJS, Alt, Redux و غیره برای پیاده سازی آن پدید آمدند. در این بین، کتابخانه‌ی Redux ماندگار شد و پیروز این نبرد بود!


توابع خالص و ناخالص (Pure & Impure Functions)

پیش از شروع بحث، نیاز است با یک‌سری از واژه‌ها مانند توابع خالص و ناخالص آشنا شد. این نکات از این جهت مهم هستند که Redux فقط با توابع خالص کار می‌کند.
توابع خالص: تعدادی آرگومان را دریافت کرده و بر اساس آن‌ها، مقداری را باز می‌گردانند.
// Pure
const add = (a, b) => {
  return a + b;
}
در اینجا یک تابع خالص را مشاهده می‌کنید که a و b را دریافت کرده و بر این اساس، یک خروجی کاملا مشخص را بازگشت می‌دهد.

توابع ناخالص: این نوع توابع سبب تغییراتی در متغیرهایی خارج از میدان دید خود می‌شوند و یا به همراه یک سری اثرات جانبی (side effects) مانند تعامل با دنیای خارج (وجود یک console.log در آن تابع و یا دریافت اطلاعاتی از یک API خارجی) هستند.
// Impure
const b;

const add = (a) => {
  return a + b;
}
تابع تعریف شده‌ی در اینجا ناخالص است؛ چون با اطلاعاتی خارج از میدان دید خود مانند متغیر b، تعامل دارد. این تعامل با دنیای خارج، حتی در حد نوشتن یک console.log:
// Impure
const add = (a, b) => {
  console.log('lolololol');
  return a + b;
}
یک تابع خالص را تبدیل به یک تابع ناخالص می‌کند و یا نمونه‌ی دیگر این تعاملات، فراخوانی سرویس‌های backend در برنامه هستند که یک تابع را ناخالص می‌کنند:
// Impure
const add = (a, b) => {
   Api.post('/add', { a, b }, (response) => {
    // Do something.
   });
};


روش‌هایی برای جلوگیری از تغییرات در اشیاء در جاوا اسکریپت

ایجاد تغییرات در آرایه‌ها و اشیاء (Mutating arrays and objects) نیز ناخالصی ایجاد می‌کند؛ از این جهت که سبب تغییراتی در دنیای خارج (خارج از میدان دید تابع) می‌شویم. به همین جهت نیاز به روش‌هایی وجود دارد که از این نوع تغییرات جلوگیری کرد:
// Copy object
const original = { a: 1, b: 2 };
const copy = Object.assign({}, original);
برای تغییری در یک شیء، تنها کافی است خاصیتی را به آن اضافه کنیم و یا با استفاده از واژه‌ی کلیدی delete، خاصیتی را از آن حذف کنیم. به همین جهت برای اینکه تغییرات ما بر روی شیء اصلی اثری را باقی نگذارند، یکی از روش‌ها، استفاده از متد Object.assign است. کار آن، یکی کردن اشیایی است که به آن ارسال می‌شوند. به همین جهت در اینجا با یک شیء خالی، از صفر شروع می‌کنیم. سپس دومین آرگومان آن را به همان شیء مدنظر، تنظیم می‌کنیم. به این ترتیب به یک کپی از شیء اصلی می‌رسیم که دیگر به آن، اتصالی را ندارد. به همین جهت اگر بر روی این شیء کپی تغییراتی را ایجاد کنیم، به شیء اصلی کپی نمی‌شود و سبب تغییرات در آن (mutation) نخواهد شد.
برای مثال در React، برای انجام رندر نهایی، در پشت صحنه کار مقایسه‌ی اشیاء صورت می‌گیرد. به همین جهت اگر همان شیءای را که ردیابی می‌کند تغییر دهیم، دیگر نمی‌تواند به صورت مؤثری فقط قسمت‌های تغییر کرده‌ی آن‌را تشخیص داده و کار رندر را فقط بر اساس آن‌ها انجام دهد و مجبور خواهد شد کل یک شیء را بارها و بارها رندر کند که اصلا بهینه نیست. به همین جهت، ایجاد تغییرات مستقیم در شیءای که به state آن انتساب داده می‌شود، مجاز نیست.

متد Object.assign، چندین شیء را نیز می‌تواند با هم یکی کند و شیء جدیدی را تشکیل دهد:
// Extend object
const original = { a: 1, b: 2 };
const extension = { c: 3 };
const extended = Object.assign({}, original, extension);
روش دیگر ایجاد یک کپی و یا clone از یک شیء را که پیشتر در سری «React 16x» بررسی کردیم، به کمک امکانات ES-6، به صورت زیر است:
// Copy object
const original = { a: 1, b: 2 };
const copy = { ...original };
در اینجا نیز ابتدا یک شیء خالی را ایجاد می‌کنیم و سپس توسط spread operator، خواص شیء قبلی را درون آن باز کرده و قرار می‌دهیم. به این ترتیب به یک clone از شیء اصلی می‌رسیم. این حالت نیز از ترکیب چندین شیء با هم، پشتیبانی می‌کند:
// Extend object
const original = { a: 1, b: 2 };
const extension = { c: 3 };
const extended = { ...original, ...extension };


روش‌هایی برای جلوگیری از تغییرات در آرایه‌ها در جاوا اسکریپت

متد slice آرایه‌ها نیز بدون ذکر آرگومانی، یک کپی از آرایه‌ی اصلی را ایجاد می‌کند:
// Copy array
const original = [1, 2, 3];
const copy = [1, 2, 3].slice();
همچنین معادل همین قطعه کد در ES-6 به همراه spread operator به صورت زیر است:
// Copy array
const original = [1, 2, 3];
const copy = [ ...original ];
و یا اگر بخواهیم یک کپی از چندین آرایه را ایجاد کنیم می‌توان از متد concat استفاده کرد:
// Extend array
const original = [1, 2, 3];
const extended = original.concat(4);
const moreExtended = original.concat([4, 5]);
متد Array.push، هرچند سبب افزوده شدن عنصری به یک آرایه می‌شود، اما یک mutation را نیز ایجاد می‌کند؛ یعنی تغییرات آن به دنیای خارج اعمال می‌گردد. اما Array.concat یک آرایه‌ی کاملا جدید را ایجاد می‌کند و همچنین امکان ترکیب آرایه‌ها را نیز به همراه دارد.
معادل قطعه کد فوق در ES-6 و به همراه spread operator آن به صورت زیر است:
// Extend array
const original = [1, 2, 3];
const extended = [ ...original, 4 ];
const moreExtended = [ ...original, ...extended, 5 ];


مفاهیم ابتدایی Redux


در Redux برای ایجاد تغییرات در شیء کلی state، از مفهومی به نام dispatch actions استفاده می‌شود. action در اینجا به معنای رخ‌دادن چیزی است؛ مانند کلیک بر روی یک دکمه و یا دریافت اطلاعاتی از یک API. در این حالت مقایسه‌ای بین وضعیت قبلی state و وضعیت فعلی آن صورت می‌گیرد و تغییرات مورد نیاز جهت اعمال به UI، محاسبه خواهند شد.
اصلی‌ترین جزء Redux، تابعی است به نام Reducer. این تابع، یک تابع خالص است و دو آرگومان را دریافت می‌کند:


تابع Reducer، بر اساس action و یا رخ‌دادی، ابتدا کل state برنامه را دریافت می‌کند و سپس خروجی آن بر اساس منطق این تابع، یک state جدید خواهد بود. اکنون که این state جدید را داریم، برنامه‌ی React ما می‌تواند به تغییرات آن گوش فرا داده و بر اساس آن، UI را به روز رسانی کند. به این ترتیب کار اصلی مدیریت state، به خارج از برنامه‌ی React منتقل می‌شود.

در این تصویر، تابع action creator را هم ملاحظه می‌کند که کاملا اختیاری است. یک action می‌تواند یک رشته و یا یک عدد باشد. با پیچیده شدن برنامه، نیاز به ارسال یک‌سری متادیتا و یا اطلاعات بیشتری از اکشن رسیده‌است. کار action creator، ایجاد شیء action، به صورت یک دست و یکنواخت است تا دیگر نیازی به ایجاد دستی آن نباشد.


مزایای کار با Redux

- داشتن یک مکان مرکزی برای ذخیره سازی کلی حالت برنامه (به آن «source of truth» و یا store هم گفته می‌شود): به این ترتیب مشکل ارسال خواص در بین کامپوننت‌های عمیق و چند سطحی، برطرف شده و هر زمانیکه نیاز بود، از آن اطلاعاتی را دریافت و یا با قالب خاصی، آن‌را به روز رسانی می‌کنند.
- رسیدن به به‌روز رسانی‌های قابل پیش بینی state: هرچند در حالت کار با Redux، یک شیء بزرگ جاوا اسکریپتی، کل state برنامه را تشکیل می‌دهد، اما امکان کار مستقیم با آن و تغییرش وجود ندارد. به همین جهت است که برای کار با آن، باید رویدادی را از طریق actionها به تابع Reducer آن تحویل داد. چون Reducer یک تابع خالص است، با دریافت یک سری ورودی مشخص، همواره یک خروجی مشخص را نیز تولید می‌کند. به همین جهت قابلیت ضبط و تکرار را پیدا می‌کند؛ همان بحث serialize و deseriliaze، توسط ابزاری مانند: logrocket. به علاوه قابلیت undo و redo را نیز می‌توان به این ترتیب پیاده سازی کرد (state جدید محاسبه شده، مشخص است، کل state قبلی را نیز داریم یا می‌توان ذخیره کرد و سپس برای undo، آن‌را جایگزین state جدید نمود). افزونه‌ی redux dev tools نیز قابلیت import و export کل state را به همراه دارد.
- چون تابع Reducer، یک تابع خالص است و همواره خروجی‌های مشخصی را به ازای ورودی‌های مشخصی، تولید می‌کند، آزمایش کردن، پیاده سازی و حتی logging آن نیز ساده‌تر است. در این بین حتی یک افزونه‌ی مخصوص نیز برای دیباگ آن تهیه شده‌است: redux-devtools-extension. تابع خالص، تابعی است که به همراه اثرات جانبی نیست (side effects)؛ به همین جهت عملکرد آن کاملا قابل پیش بینی بوده و آزمون پذیری آن به دلیل نداشتن وابستگی‌های خارجی، بسیار بالا است.


Context API خود React چطور؟

در قسمت 33 سری React 16x، مفهوم React Context را بررسی کردیم. پس از معرفی آن با React 16.3، مقالات زیادی منتشر شدند که ... Redux مرده‌است (!) و یا بجای Redux از React context استفاده کنید. اما واقعیت این است که React Redux در پشت صحنه از React context استفاده می‌کند و تابع connect آن دقیقا به همین زیر ساخت متصل می‌شود.
کار با Redux مزایایی مانند کارآیی بالاتر، با کاهش رندر‌های مجدد کامپوننت‌ها، دیباگ ساده‌تر با افزونه‌های اختصاصی و همچنین سفارشی سازی، مانند نوشتن میان‌افزارها را به همراه دارد. اما شاید واقعا نیازی به تمام این امکانات را هم نداشته باشید؛ اگر هدف، صرفا انتقال ساده‌تر اطلاعات بوده و برنامه‌ی مدنظر نیز کوچک است. React Context برخلاف Redux، نگهدارنده‌ی state نیست و بیشتر هدفش محلی برای ذخیره سازی اطلاعات مورد استفاده‌ی در چندین و چند کامپوننت تو در تو است. هرچند شبیه به Redux می‌توان اشاره‌گرهایی از متدها را به استفاده کنندگان از آن ارسال کرد تا سبب بروز رویدادها و اکشن‌هایی در کامپوننت تامین کننده‌ی Contrext شوند (یا یک کتابخانه‌ی ابتدایی شبیه به Redux را توسط آن تهیه کرد). بنابراین برای انتخاب بین React Context و Redux باید به اندازه‌ی برنامه، تعداد نفرات تیم، آشنایی آن‌ها با مفاهیم Redux دقت داشت.
مطالب
پیاده سازی الگوی طراحی Memento

Memento یک الگوی طراحی مفید و ساده است که برای ذخیره و بازیابی state یک object استفاده می‌شود. در بعضی از مقالات از آن به عنوان snapshot نیز یاد شده است! اگر با git  کار کرده باشید، این مفهوم را می‌توان در git بسیار یافت؛ هر commit به عنوان یک snapshot میباشد که میتوان به صورت مکرر آن را undo کرد و یا مثال خیلی ساده‌تر میتوان به ctrl+z در سیستم عامل اشاره کرد.

به مثال زیر توجه کنید:

Int temp;
Int a=1;
temp=a;
a=2;
.
.
a=temp;

شما قطعا در برنامه نویسی با کد بالا زیاد برخورد داشته‌اید و آن‌را به صورت مکرر انجام داده‌اید. کد بالا را در قالب یک object بیان میکنیم. به مثال زیر توجه کنید:

int main()
{
  MyClass One = new MyClass();
  MyClass Temp = new MyClass();
  // Set an initial value.
  One.Value = 10;
  One.Name = "Ten";
  // Save the state of the value.
  Temp.Value = One.Value;
  Temp.Name = One.Name;
  // Change the value.
  One.Value = 99;
  One.Name = "Ninety Nine";
  // Undo and restore the state.
  One.Value = Temp.Value;
  One.Name = Temp.Name;
}

در کد بالا با استفاده از یک temp، شیء مورد نظر را ذخیره کرده و در آخر مجدد داده‌ها را درون شیء، restore  میکنیم.


 از مشکلات کد بالا میتوان گفت :

۱- برای هر object باید یک شیء temp ایجاد کنیم.

۲- ممکن است بخواهیم که حالات یک object را بر روی هارد ذخیره کنیم. با روش فوق کدها خیلی پیچیده‌تر خواهند شد.

۳- نوشتن کد به این سبک برای پروژه‌های بزرگ، پیچیده و مدیریت آن سخت‌تر می‌شود.


پیاده سازی memento

ما این مثال را در قالب یک پروژه NET Core  onsole. ایجاد میکنیم. برای این کار یک پوشه‌ی جدید را ایجاد و درون ترمینال دستور زیر را وارد کنید:

dotnet new console

روش‌های زیادی برای پیاده سازی memento وجود دارند. برای پیاده سازی memento ابتدا یک abstract class را به شکل زیر ایجاد میکنیم: 

abstract class MementoBase
{
  protected Guid mementoKey = Guid.NewGuid();
  abstract public void SaveMemento(Memento memento);
  abstract public void RestoreMemento(Memento memento);
}

اگر به کلاس بالا دقت کنید، این کلاس قرار است parent کلاس‌های دیگری باشد که داری دو متد SaveMemento و RestoreMemento برای ذخیره و بازیابی و همچنین یک Guid برای نگهداری state‌های مختلف میباشد.

ورودی متدها از نوع memento میباشد. پس کلاس memento را به شکل زیر ایجاد می‌کنیم:

class Memento
{
    private Dictionary<Guid, object> stateList = new Dictionary<Guid, object>();
    public object GetState(Guid key)
    {
        return stateList[key];
    }
    public void SetState(Guid key, object newState)
    {
        stateList[key] = newState;
    }
    public Memento()
    {
    }
}

در کد بالا با یک Dictionary می‌توان هر object را با کلیدش ذخیره کنیم. توجه کنید که value دیکشنری از نوع object میباشد و چون object پدر تمام object‌های دیگر است پس می‌توانیم هر نوع داده‌ای را در آن ذخیره کنیم. تا اینجا، Memento پیاده سازی شده است. میتوان این کار را با جنریک‌ها نیز پیاده سازی کرد.

در ادامه می‌خواهیم یک کلاس بسازیم و حالت‌های مختلف را در آن بررسی کنیم. کلاس زیر را ایجاد کنید:

class ConcreteOriginator : MementoBase
{
  private int value = 0;
  public ConcreteOriginator(int newValue)
  {
    SetData(newValue);
  }
  public void SetData(int newValue)
  {
    value = newValue;
  }
  public void Speak()
  {
    Console.WriteLine("My value is " + value.ToString());
  }
  public override void SaveMemento(Memento memento)
  {
    memento.SetState(mementoKey, value);
  }
  public override void RestoreMemento(Memento memento)
  {
    int restoredValue = (int)memento.GetState(mementoKey);
    SetData(restoredValue);
  }
}

کلاس ConcreteOriginator از کلاس MementoBase ارث بری کرده و دو متد RestoreMemento و SaveMemento را پیاده سازی میکند و همچنین دارای یک مشخصه value می‌باشد. برای خروجی گرفتن، متد main را به صورت زیر پیاده سازی می‌کنیم:

static void Main(string[] args)
{
  Memento memento = new Memento();
  // Create an originator, which will hold our state data.
  ConcreteOriginator myOriginator = new ConcreteOriginator("Hello World!", StateType.ONE);
  ConcreteOriginator anotherOriginator = new ConcreteOriginator("Hola!", StateType.ONE);
  ConcreteOriginator2 thirdOriginator = new ConcreteOriginator2(7);
  // Set some state data.
  myOriginator.Speak();
  anotherOriginator.Speak();
  thirdOriginator.Speak();
  // Save the states into our memento.
  myOriginator.SaveMemento(memento);
  anotherOriginator.SaveMemento(memento);
  thirdOriginator.SaveMemento(memento);
  // Now change our originators' states.
  myOriginator.SetData("Goodbye!", StateType.TWO);
  anotherOriginator.SetData("Adios!", StateType.TWO);
  thirdOriginator.SetData(99);
  myOriginator.Speak();
  anotherOriginator.Speak();
  thirdOriginator.Speak();
  // Restore our originator's state.
  myOriginator.RestoreMemento(memento);
  anotherOriginator.RestoreMemento(memento);
  thirdOriginator.RestoreMemento(memento);
  myOriginator.Speak();
  anotherOriginator.Speak();
  thirdOriginator.Speak();
  Console.ReadKey();
}
تا خط ۱۲، مراحل عادی کد نویسی را پیش رفته‌ایم. در خطوط ۱۳ تا ۱۵، داده را در Memento ذخیره میکنیم. در خطوط ۱۷ تا ۱۹، داده‌های اشیاء را با استفاده از متد SetData عوض میکنیم. در خطوط ۲۰ تا ۲۲ با متد Speak، مقدار value را نمایش میدهیم و در خطوط ۲۴ تا ۲۶، داده‌ها را Restore میکنیم و در آخر دوباره مقدار value را نمایش میدهیم.
برنامه را اجرا کنید .خروجی به شکل زیر خواهد بود:
Hello World! I'm in state ONE
Hola! I'm in state ONE
My value is 7
Goodbye! I'm in state TWO
Adios! I'm in state TWO
My value is 99
Hello World! I'm in state ONE
Hola! I'm in state ONE
My value is 7
مطالب
پیاده‌سازی میکروسرویس‌ها توسط Seneca
همانطور که در مطلب آشنایی با معماری Microservices گفته شد، Seneca یک فریم‌ورک مبتنی بر Node.js برای ساخت برنامه‌های سمت سرور بر مبنای معماری Microservices با هسته Monolithic است. در این مطلب قصد ارائه یک مثال عملی را بر اساس این فریم‌ورک ندارم. هدف، آشنایی با اجزای اصلی Seneca و چهارچوب کاری آن است.


فواید استفاده از فریم‌ورک Seneca  

  • فریم‌ورک Seneca کدنویسی برای ایجاد درخواست‌ها، ارسال پاسخ به درخواست‌های رسیده و تبدیل داده‌ها را که از روتین‌های هر سرویسی میتوانند باشند، ساده‌تر میکند.
  • فریم‌ورک Seneca با معرفی ایده Actionها و Pluginها که جلوتر توضیح داده خواهند شد، روند تبدیل کامپوننت‌های یک برنامه Monolithic را به نوع سرویسی، تسهیل میکند. روندی که به صورت عادی میتواند کاری طاقت فرسا باشد و نیاز به Refactoring زیادی دارد. 
  • سرویس‌های نوشته شده با زبانهای برنامه‌نویسی مختلف یا فریم‌ورک‌های متفاوت میتوانند با سرویس‌های نوشته شده توسط فریم‌ورک Seneca در ارتباط و تبادل باشند.


نصب فریم‌ورک Seneca

نصب Seneca تفاوتی با نصب سایر فریم‌ورک‌ها توسط npm ندارد. مثلا میشود فایلی با نام package.json را با تنظیماتی که در پی خواهد آمد داشت و با اجرای دستور npm install در خط فرمان، Seneca را نصب کرد. البته دستور نصب را باید در پوشه‌ای که فایل package.json در آن  ایجاد شده‌است، اجرا کرد.
{
    "name": "seneca-example",
    "dependencies": {
        "seneca": "0.6.5",
        "express": "latest"
    }
}
بعد برای استفاده از فریم‌ورک نصب شده باید نمونه‌ای از آن را ایجاد کنیم. 
var seneca = require("seneca")();

 Actionها

‌Actionها عملکرد بخصوصی را ارائه می‌دهند که باید به نمونه‌ای از فریم‌ورک Seneca که ایجاد کرده‌ایم، اضافه شوند. اینکه یک Action چه عملکرد بخصوصی را ارائه می‌هد، در زمان اضافه کردن آن به نمونه‌ای ایجاد شده، مشخص می‌شود. در مطلب گذشته گفته شد که برای تغییر یک برنامه Monolithic به نوع سرویسی، می‌شود فقط کامپوننت‌های دردسر ساز را تغییر داد. Actionها عملکردهای آن کامپوننت‌های مشکل ساز را به عهده خواهند گرفت. زمان اضافه کردن یک Action به نمونه‌ای از Seneca، از متد add استفاده میکنیم که دو آرگومان را دریافت میکند. اولین آرگومان، یک رشته JSON یا یک object است که هویت عملکرد Action را نشان می‌دهد و دومی در واقع یک متد Callback است و زمانیکه Action فراخوانی میشود، اجرا خواهد شد.  
seneca.add({role: "accountManagement", cmd: "login"}, function(args, respond){
});
seneca.add({role: "accountManagement", cmd: "register"}, function(args, respond){
});
در مثال بالا دو Action را به نمونه‌ای از Seneca اضافه کرده‌ایم. خواص role و cmd موارد بخصوصی نیستند. می‌شود آن‌ها را با  موارد دلخواه، بسته به عملکردی که از Action انتظار داریم، جایگزین کنیم. برای فراخوانی Actionهایی که اضافه کرده‌ایم، باید از متد act استفاده کنیم. البته متد act میتواند Actionهایی را که در سایر سرویس‌ها قرار دارند هم فراخوانی کند. اولین آرگومان act، برای تطبیق با الگوهایی که در زمان اضافه کردن Actionها به نمونه تنظیم شده‌اند، استفاده می‌شود. دومین آرگومان آن هم باز یک Callback است و در زمانیکه Action فراخوانی شده‌است اجرا میشود. 
seneca.act({role: "accountManagement", cmd: "register", username:
"parham", password: "12345!"}, function(error, response){
});

seneca.act({role: "accountManagement", cmd: "login", username:
"parham", password: "12345!"}, function(error, response){
});
در مثال بالا و در پارامتر اول، مشخصه‌های بیشتری نسبت به الگوی Actionهایی که اضافه کرده‌ایم، دیده می‌شود. این مسئله مشکلی ایجاد نمیکند و به هر حال Seneca تمامی الگوهای مشابه را شناسایی میکند و آن موردی که بیشترین تطبیق را دارد، فرا میخواند. 


Pluginها

  Pluginها در Seneca در واقع بسته بندیهایی از Actionهایی هستند که کاربرد مشابهی دارند. در مثال بالا دو Action داشتیم که یکی عملکرد ورود را برعهده دارد و دیگری ثبت‌نام. از آنجایی که هر دو برای بخش مدیریت کاربران تشابهاتی دارند، می‌شود آنها را در یک Plugin بسته بندی کرد. ارزش Pluginها زمانی است که می‌خواهیم آنها را توزیع کنیم. با توزیع Plugin، تمام Actionهای زیرمجموعه آن همزمان توزیع می‌شوند. Pluginها را میشود در قالب توابع یا ماژول‌ها ایجاد کرد.
function account(options){
    this.add({init: "account"}, function(pluginInfo, respond){
        console.log(options.message);
        respond();
    })  

    this.add({role: "accountManagement", cmd: "login"}, function(args, respond){
     }); 

    this.add({role: "accountManagement", cmd: "register"}, function(args, respond){
    });
}

seneca.use(account, {message: "Plugin Added"});
در مثال بالا از روش تابع برای ایجاد Plugin استفاده شده‌است. Plugin را ایجاد می‌کنیم و Actionهایی را که میخواهیم به Plugin اضافه شوند، توسط this اضافه می‌کنیم و در نهایت با متد use به نمونه Seneca میگوییم که از Plugin ساخته شده، استفاده کند. کلمه کلیدی This درون Plugin به نمونه‌ای از Seneca که ایجاد کرده‌ایم، ارجاع دارد. یعنی هر this.add برابر با seneca.add می‌باشد. نکته باقی مانده، Action اضافه‌ای است با مشخصه {init: "account"} که چه نقشی دارد. این Action نقش یک سازنده را برای مقداردهی اولیه، دارد. برای نمونه میشود از آن برای ارتباط با پایگاه داده، پیش از اجرا شدن سایر Actionها که نیاز به آن ارتباط دارند، استفاده کرد. مثال بالا را می‌شود با یک ماژول هم پیاده‌سازی کرد.
module.exports = function(options){
    this.add({init: "account"}, function(pluginInfo, respond){
        console.log(options.message);
        respond();
    })

    this.add({role: "accountManagement", cmd: "login"}, function(args, respond){
    });

    this.add({role: "accountManagement", cmd: "register"},function(args, respond){
    });

    return "account";
}  

seneca.use("./account.js", {message: "Plugin Added"});
 ماژول، نام Plugin را برگشت میدهد که با فرض بر اینکه ماژول در فایل account.js قرار دارد، با متد use به نمونه Seneca میگوییم که از Plugin ساخته شده استفاده کند.


Serviceها  

یک سرویس، یک نمونه از فریم‌ورک Seneca است که Actionهایی را برای استفاده بیرونی، در معرض شبکه قرار می‌دهد. 
var seneca = require("seneca")();
seneca.use("./account.js", {message: "Plugin Added"});
seneca.listen({port: "9090", pin: {role: "accountManagement"}});
در مثال بالا، نمونه‌ای از فریم‌ورک Seneca ایجاد شده، مجموعه‌ای از Actionها تحت یک Plugin به آن اضافه شده و در نهایت Actionهایی که در زمان ساخت و اضافه کردن آنها نقش accountManagement گرفته‌اند، برای استفاده در معرض شبکه و در بستر HTTP قرار می‌گیرند. هر دو بخش port و pin، اختیاری هستند و با صرفنظر از این دو بخش، اولا نمونه‌ی Seneca برای دریافت درخواست‌های ورودی، به درگاه پیش فرض 10101 گوش می‌دهد و ثانیا تمامی Actionهایی را که به نمونه اضافه کرده‌ایم، در معرض شبکه قرار میگیرند.
در سمت دیگر، برای اینکه سایر سرویس‌ها و برنامه‌های Monolithic قادر باشند Actionهای در معرض شکبه قرار داده شده را فراخوانی کنند، باید آنچه را که در معرض قرار داده شده، در خود ثبت کنند. برای مثال سرویس دیگری از Seneca می‌تواند از قطعه کد زیر استفاده کند.
seneca.client({port: "9090", pin: {role: "accountManagement"}});

در اینجا هم موارد port و pin اختیاری هستند. اگر سرویسی که میخواهیم ثبت کنیم در سرور دیگری باشد، بایستی خاصیت host و با مقدار آدرس IP سرور مورد نظر در زمان ثبت، اعمال شود. سوالی که باقی می‌ماند این است که یک سرویس چطور Actionی از یک سرویس دیگر را فراخوانی می‌کند؟

در بخش Actionها آمد که برای فراخوانی یک Action از متد act،  از نمونه‌ی Seneca استفاده میکنیم. رفتار Seneca به این صورت است که ابتدا بر اساس امضای Action درخواست شده، Actionهای محلی را که به سرویس جاری اضافه شده‌اند، جستجو میکند. اگر تطبیقی نیافت به سراغ Actionهای ثبت شده خارجی که دارای خاصیت pin هستند، خواهد رفت و در نهایت اگر آنجا هم موردی نیافت، برای تک تک سرویس‌هایی که آنها را ثبت کرده، اما خاصیت pin را ندارند، درخواستی را ارسال میکند.


برای اطلاعات بیشتر به بخش مستندات  فریم‌ورک Seneca رجوع کنید.

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


 معماری Monolithic چیست؟ 

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


مشکلات معماری Monolithic

  •  در معماری Monolithic زمانیکه ترافیک برنامه در سمت سرور افزایش پیدا میکند، باید برای پاسخگویی، اندازه را افزایش داد. یعنی باید برنامه تحت وب خود را بر روی سرورهای مختلف مجددا اجرا نمود. بخشی به نام Load Balancer، وظیفه توزیع درخواست‌ها را به سرورهای مختلف که بر روی هر یک، یک نسخه از برنامه در حال اجرا است، به عهده دارد. بر اساس توضیحی که از این معماری ارایه شد، در هر یک از این اجرا‌ها، کل برنامه با تمام متعلقاتی که دارد، فارغ از اینکه به همه آنها نیاز است یا نه، از منابع سرور استفاده میکند.

  • در معماری Monolithic برنامه‌ها بر اساس یک زبان برنامه‌نویسی مشخص، برای یک فریم ورک مشخص نوشته می‌شوند. این برنامه‌ها اصطلاحا چند سکویی نیستند و کامپوننت‌های نوشته شده برای آنها فقط در فریم ورک جاری قابل استفاده مجدد هستند.
  • ممکن است برای هر تغییر ریز و درشت در برنامه‌های این معماری، نیاز به Build و Deploy مجدد کل برنامه باشد که احتمال از دسترس خارج شدن برنامه هم وجود دارد.
  • اگر بخشی از برنامه از کار بیافتد، ممکن است باعث از کار افتادن کل برنامه یا بخشهایی از آن شود. 


معماری Microservices

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

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


 ارزش معماری Microservices

  • از آنجایی که سرویس‌ها از طریق زبان مشترک شبکه با یکدیگر در ارتباط هستند، میشود آنها را با زبانهای برنامه‌نویسی مختلف و بر روی فریم‌فرک‌های متفاوت نوشت. 
  • بدیهی است که با این معماری، هر سرویس را میشود به صورت جداگانه ایجاد کرد و تغییر داد که باعث سرعت در به روزرسانی و فرآیند گسترش برنامه میشود.
  • مانیتور کردن سرویس‌ها ساده‌تر خواهد بود. از آنجایی که هر سرویس به صورت یک پردازش جداگانه اجرا خواهد شد، تعیین اینکه هر سرویس از چه منابعی و به چه اندازه‌ای استفاده میکند، آسان‌تر خواهد بود.
  • از آنجایی که این سرویس‌ها از طریق شبکه در تبادل هستند، میشود از آنها در سایر برنامه‌ها مجدداً استفاده کرد. 


افزایش یک سرویس خاص

 یکی از با ارزش‌ترین قابلیت‌های معماری Microservices، افزایش یک سرویس، که به عنوان مثال فقط یک وهله از آن در حال اجراست، به دو یا سه وهله جداگانه است؛ بدون آنکه نیاز باشد سرویس‌های در ارتباط با آنها نیز وهله سازیهای اضافه‌ای داشته باشند. این حالت در دیاگرام زیر قابل مشاهده است. 

 در دیاگرام بالا از سرویس یک، دو وهله، در دو سرور جداگانه ایجاد شده است که Load Balancer ترافیک ورودی را بین آنها تقسیم میکند. باقی سرویس‌ها به همان تعداد که بودند باقی می‌مانند.


مشکلات معماری Microservices

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


چه زمانی از معماری Microservices استفاده کنیم؟

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

 

 مدیریت داده‌ها: 

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


پیاده‌سازی معماری Microservices‌ها توسط فریم‌فرک Seneca

Seneca یک فریم ورک Node.js است که برای ساخت برنامه‌های سمت سروری با معماری Microservices و هسته Monolithic استفاده می‌شود. در مطلب بعدی به این فریم‌ورک نگاهی گذرا خواهیم داشت.
مطالب
Feature Toggle
در بسیاری از پروژه‌های نرم افزاری ما ممکن است یک امکان (Feature) را برای بازه‌ی زمانی خاصی بنا به درخواست مشتری یا ضوابط خودمان نیاز داشته باشیم و در زمان دیگری یا برای مشتری دیگری نیاز نداشته باشیم و باید قابلیت مورد نظر غیر فعال باشد. یا حتی ممکن است قابلیتی را به تازگی افزوده باشیم، ولی در زمان اجرا خطایی داشته باشد و مجبور باشیم فورا آن را از دسترش خارج کنیم. به این فرایند در اصلاح Feature Toggle میگویند که البته نام‌های دیگری از جمله (feature switch, feature flag, feature flipper, conditional feature ) هم دارد. مارتین فاولر آن را این چنین تعریف میکند:
"Feature Toggling" is a set of patterns which can help a team to deliver new functionality to users rapidly but safely
"Feature Toggling" تکنیک قدرتمندی است که به ما این اجازه را میدهد تا رفتار سیستم را بدون تغییر کد عوض کنیم.
ساده‌ترین الگوی پیاده سازی Feature Toggling چیزی شبیه به نمونه زیر می‌باشد. یک اینترفیس که باید مشخصه یا متدی برای بررسی فعال بودن و نبودن داشته باشد.
 public interface IFeatureToggle {
   bool FeatureEnabled {get;}  
}
برای اینکه اصل قابل تنظیم بودن (Configurable) را هم رعایت کرده باشیم، بررسی فعال بودن کامپوننت را از طریق وب کانفیگ انجام میدهیم.
class ShowMessageToggle : IFeatureToggle  
 {   
    public bool FeatureEnabled {
     get{
           return  bool.Parse(ConfigurationManager.AppSettings["ShowMessageEnabled"]);      
        }
 }
و حالا کافی است در هر جایی که قصد استفاده از آن کلاس را داشته باشیم، فعال بودن و نبودنش را بررسی کنیم.
class Program
 {
 static void Main(string[] args)
   {
     var toggle = new ShowMessageToggle();
     if (toggle.FeatureEnabled)
     {
        Console.WriteLine("This feature is enabled")
     }
     else
     {  
         Console.WriteLine("This feature is disabled");            
     }
   }  
 }
مثال بالا ساده‌ترین نحوه‌ی استفاده از Feature Toggling بود. اما شبیه الگوی IOC که ابزارهای زیادی برای پیاده سازی آن عرضه شده است، برای این الگو هم ابزارهای جالبی تولید شده است که به‌راحتی این قابلیت را در پروژه‌های ما ایجاد و نگهداری میکند. لیستی از این ابزارها و پکیج‌ها را از اینجا میتوانید ببینید.
بطور مثال برای کار با FeatureToggle ابتدا آنرا با دستور زیر نصب میکنیم:
Install-Package FeatureToggle
سپس کلاس مورد نظر را از کلاس پایه SimpleFeatureToggle ارث بری میکنیم.
MyAwesomeFeature : SimpleFeatureToggle {}
در  فایل کانفیگ برنامه یک تنظیم جدید را با نام کلاس مذکور ایجاد میکنیم:
<add key="MyAwesomeFeature " value="true" />
حالا هرجای برنامه نیاز داشتید میتوانید فعال بودن و نبودن قابلیت‌های مختلف را بررسی کنید.
if (!myAwesomeFeature.FeatureEnabled)
{ // code to disable stuff (e.g. UI buttons, etc) }
شما به همین سادگی و سرعت، میتوانید قابلیت Feature Toggle را در پروژه‌هایتان راه اندازی کنید.

لیست منابع
 http://nugetmusthaves.com/Tag/toggle 
http://featureflags.io/dotnet-feature-flags/ 
http://martinfowler.com/articles/feature-toggles.html
مطالب
تگ گذاری در کامنت‌ها
در محیط‌های برنامه نویسی مدرن و امروزی، استفاده از تگ‌ها در کامنت‌ها (CommentTag) رواج بسیاری دارد که یکی از معروفترین این تگ‌ها، تگ TODO است. این نوع تگ‌ها که عموما به همراه یک توضیح کوتاه یا عنوان به کار می‌روند، برای این است که بتوانیم از طریق ابزارهایی که ادیتورها در اختیارمان قرار می‌دهند، آن‌ها را پیدا کنیم. حتی در سیستم‌های لینوکسی میتوان با دستور Grep به جست و جوی آن‌ها پرداخت. عموما تگ‌ها با حروف بزرگ نوشته می‌شوند؛ ولی اجباری در آن نیست ولی رعایت آن بهتر است. نام‌های دیگری که برای این تگ‌ها به کار می‌رود Token و Codetag می‌باشد. از معروفترین تگ ها، می‌توان به تگ‌های زیر اشاره کرد:

TODO : معروفترین تگ شناخته شده‌است و میتوان گفت در اکثر اوقات به جای بقیه هم استفاده می‌شود. چون معنای دیگر کامنت‌ها را نیز در بر می‌گیرد. این نوع کامنت به شما می‌گویند که این کد نیاز دارد در یک زمان معین و سر فرصت به آن رسیدگی شود. به عنوان مثال بهتر است ویژگی خاصی را به کدی اضافه کرد، یا مورد خاصی بهتر است در آن پیاده سازی شود و یا نیاز به ویرایش خاصی دارد که پیاده سازی آن منفعتی دارد و این کامنت برای این است که به برنامه نویس یادآوری کند تا در دفعات آتی به این کد رسیدگی کند. سپس در دفعات آتی برنامه نویس میتواند با استفاده از ابزاری که ادیتور در اختیار وی قرار میدهد، این نوع کامنت‌ها را پیدا کند.

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

UNDONE : این تگ برای اصلاح یا تغییر نیست. ولی به شما میگوید که قبلا این کد چگونه بوده است و چه تغییراتی کرده است.  قبلا چه چیزهایی در کد پیاده سازی شده بوده است که الان در کد وجود ندارد و چرا حذف شده است.

HACK : گاهی اوقات در کدها، باگ هایی رخ میدهند که مجبور به استفاده از راه‌های غیرعادی برای رفع آن می‌شوید. این نوع روش‌های رفع مشکل، روش‌ها و راه حل‌های مناسبی نیستند؛ ولی می‌توانند به طور موقت و در زمان سریعتری پاسخگوی ما باشند. برنامه نویس بعد از رفع مشکل، با درج این نوع کامنت، در آینده به خود یادآوری میکند که این کد نیاز به راه حل مناسب‌تری دارد.
 
BUGBUG : این کامنت توسط برنامه نویس کد مربوطه درج می‌شود و مربوط به زمانی است که برنامه نویس کد را نوشته است، ولی اطمینانی از صحت آن ندارد. پس برنامه نویس نیاز دارد اطلاعات بیشتری را در مورد این مسئله بیابد.
    // BUGBUG: I'm sure these GUIDs are defined somewhere but I'm not sure which library contains them, so defining them here.
    DEFINE_GUID(IID_IFoo, 0x12345678,0x1234,0x1234,0x12,0x12,0x12,0x12,0x12,0x12,0x12,0x12);

XXX :  به برنامه نویس هشدار می‌دهد که این کد راه حل‌های نادرستی دارد و احتمالا بر اساس اطلاعات نادرستی این کد شکل گرفته است، ولی در حال حاضر کار میکند.

در ویژوال استادیو، پنل taskList برای نمایش این تگ‌ها به کار می‌رود و از تگ‌های HACK,UNDONE و TODO به طور پیش فرض پشتیبانی می‌کند. در صورتی که تمایل دارید تگ‌های اضافه‌تری داشته باشید یا ترتیب اولویت نمایش تگ‌ها در پنل taskList را تغییر دهید، مسیر زیر را طی کنید:
Tools>Options>Environment>Task List

در اندروید استادیو هم دو تگ اول لیست پشتیبانی می‌شوند. در اندروید استادیو شما می‌توانید برای todo هایتان الگو و فیلتر تعریف کنید. برای اینکار ابتدای ادیتور را باز کرده و در بخش Editor گزینه Todo را انتخاب کنید. در لیست بالا می‌توانید یک نمونه الگو برای todo خاص خود اضافه کنید. به عنوان مثال تگ‌های نامبرده در بالا را اضافه کنید و برای آن آیکن و نحوه رنگبندی و قلم و ... را برای نمایش آن انتخاب کنید.


در لیست پایینی که بخش فیلترهاست، میتوانید یک فیلتر را تعریف کنید تا بر اساس این فیلتر مشخص کنید که چه todo هایی نمایش یابند. برای فیلتر کردن در در پنل todo، در نوار ابزار، آیکن قیفی شکل را کلیک کند تا لیست فیلترها نمایش یابند.

نحوه صحیح قرار دادن یک todo به شکل زیر است:

// TODO:2008-12-06:johnc:Add support for negative offsets.
// While it is unlikely that we get a negative offset, it can
// occur if the garbage collector runs out of space.
بعد از ذکر نام تگ، تاریخ را بر اساس سال، ماه و روز وارد کرده و سپس نام شخصی که این کامنت را قرار داده است و در ادامه عنوان مناسبی را که گویای مطلب باشد، انتخاب کنید. در خط‌های بعدی هم توضیح کوتاهی که مدنظر شماست. در این حالت با استفاده از ابزار unix grep میتوانید گزارش گیری مناسبی هم داشته باشید.
مطالب
الگوی شیء نال Null Object Pattern
این الگو شاید به نظر ساده برسد، ولی در بعضی موارد می‌تواند در سطوح بالاتر، کدهای تمیزتر و خلوت‌تری را در اختیار شما بگذارد. در مورد این الگو، در کتاب توسعه چابک عمو باب نیز آمده است. بسیاری ممکن است نسبت به این الگو جبهه بگیرند و بگویند که بررسی نال بودن یک شیء بهتر است و یا حتی رخ دادن خطای Null Pointer Exception در برنامه باعث می‌شود بتوانیم باگ‌ها را پیدا کنیم. در جواب باید گفت که این الگو قرار نیست در همه جا مورد استفاده قرار گیرد. در مثال زیر می‌توانید تا حدی به جایگاه استفاده از این الگو برسید. اینکه چگونه و در کجا از یک الگو استفاده کنید، به عهده برنامه نویس است.
کار این الگو در یک جمله این است که اگر متدی نتواند خروجی مناسبی را بدهد و به جای آن قرار باشد نال را برگشت دهد، به جای برگشت دادن نال، از یک شیء که هیچ رفتاری ندارد استفاده می‌کند و آن شیء را برمی‌گرداند تا در ادامه کد، بررسی نال بودن، یا خطای NPE رخ ندهد.

به عنوان مثال فرض کنید قرار است یک کاربر با نام کاربری Ali به سیستم وارد شود؛ در اینجا سه حالت وجود دارد:
  1. این کاربر یافت شده و اجازه دسترسی دارد.
  2. این کاربر یافت شده و اجازه دسترسی ندارد.
  3. این کاربر یافت نمی‌شود.

اگر در حالتیکه کاربر یافت نشود، بخواهیم نال برگردانیم، در ادامه‌ی کد باید بررسی نال بودن و یا گاها انتظار خطای NPE را داشته باشیم؛ یا اینکه در عوض از الگوی شیء نال بهره ببریم.

بدون استفاده از الگو
در این مثال ابتدا کلاس یوزر را می‌سازیم:
 public class User
    {
        public String Usernam { get; set; }
        public bool Authenticated { get; set; }
    }
در لایه سرویس هم خروجی را برمی‌گردانیم:
 public User GeUser(string uname)
        {
            if (uname == "Ali")
            {
                return new User()
                {
                    Usernam = "Ali",
                    Authenticated = true
                };
            }
            else if (uname == "Reza")
            {
                return new User()
                {
                    Usernam = "Reza",
                    Authenticated = false
                };
            }
            else
            {
                return null;
            }
        }
در این حالت کد بعدی شما باید اینگونه باشد:
 var userServices=new UserServices();
            var user = userServices.GeUser("Ali");
            if (user != null && user.Authenticated)
            {
                Console.WriteLine("You are Authorized");
            }
همانطور که می‌بینید یک خط کد شرطی به سیستم اضافه شد و در یک سیستم بزرگتر این بررسی‌ها بیشتر شده و حتی در بعضی نقاط ممکن است با یک عدم بررسی، وقوع خطای NPE را افزایش دهید. حالا همین مثال بالا را با همین الگو جلو می‌بریم.

استفاده از الگو

ابتدا یک کلاس جدید را با ارث بری از کلاس یوزر می‌سازیم:
public class NullUser:User
    {
        public NullUser()
        {
            Authenticated = false;
        }
    }
این کلاس همان شیء نالی است که قرار است به جای خود عبارت Null برگشت دهیم:
  public User GeUser(string uname)
        {
            if (uname == "Ali")
            {
                return new User()
                {
                    Usernam = "Ali",
                    Authenticated = true
                };
            }
            else if (uname == "Reza")
            {
                return new User()
                {
                    Usernam = "Reza",
                    Authenticated = false
                };
            }
                return new NullUser();
        }
بدین ترتیب در ادامه کد الزامی به بررسی نال نیست:
var userServices=new UserServices();
            var user = userServices.GeUser("xxx");
            if (user.Authenticated)
                Console.WriteLine("You are Authorized");

یک نکته اضافه تر اینکه، در صورتی که قصد دارید متدی را در کلاس پدر تحریف کنید، بهتر است یک اینترفیس یا کلاس انتزاعی را تعریف و هر دو کلاس را از آن ارث بری کنید که برای مثال بالا می‌شود اینترفیس IUser و  دو کلاس User و NullUser هم مشتقات آن.