الگوی Composite در عمل یک Collection Pattern (الگوی مجموعه ای) است. که می‌توان در درون آن ترکیبی از زیر مجموعه‌های مختلف را قرار داد و سپس هر زیر مجموعه را به نوبه خود فراخوانی نمود.به بیان دیگر الگوی Composite به ما کمک می‌کند که در یک ساختار درختی بتوانیم مجموعه ای (Collection ی)،از بخشی از آبجکتهای سلسله مراتبی را نمایش دهیم. این الگو به Client اجازه می‌دهد، که رفتار یکسانی نسبت به یک Collection ی از آبجکتها یا یک آبجکت تنها داشته باشد.

مثالهای متعددی می‌توان از الگوی Composite زد، که در ذیل به چند نمونه از آنها می‌پردازیم:

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

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

نمونه سوم: یک File System را در نظر بگیرید،که ساختارش از File و Folder تشکیل شده است. و می‌تواند یک ساختار سلسله مراتبی داشته باشد.بطوریکه درون هر Folder می‌تواند یک یا چند File یا Folder قرار گیرد. و در درون Folder‌های زیر مجموعه می‌توان چندین File یا Folder دیگر قرار داد.اگر بخواهیم به عنوان نمونه شکل ساختار درختی File و فولدر را نمایش دهیم بصورت زیر خواهد بود:

در ساختار درختی به Folder شاخه یا Branch گویند، چون می‌تواند زیر شاخه‌های دیگری نیز در خود داشته باشد. و به File برگ یا Leaf گویند.برگ نمی‌تواند زیر مجموعه ای داشته باشد. در واقع برگ (Leaf) بیانگر انتهای یک شاخه می‌باشد.

نمونه آخر:می توان به ساختار منوها در برنامه‌ها اشاره نمود.هر منو می‌تواند شامل چندین زیر منو باشد. و همان زیر منوها می‌توانند از چندین زیر منوی دیگر تشکیل شوند. این ساختار نیز یک ساختار سلسله مراتبی می‌باشد، و برای نگهداری آبجکتهای یک مجموعه می‌توان از الگوی Composite استفاده نمود.

الگوی Composite از سه Component اصلی تشکیل شده است،که یکایک آنها را بررسی می‌کنیم:

• Component: کلاس پایه ای است که در آن متدها یا Functionality‌های مشترک تعریف می‌گردد. Component می‌تواند یک Abstract Class یا Interface باشد.
• Leaf : به آبجکتهای گفته می‌شود که هیچ Child ی ندارند. و فقط یک آبجکت مستقل تنها می‌باشد. کلاس Leaf متدهای مشترک تعریف شده در Component  را پیاده سازی می‌کند.اگر مثال File و Folder را بخاطر آورید،File یک آبجکت از نوع Leaf است چون نمی‌تواند هیچ فرزندی داشته باشد و یک آبجکت تنها می‌باشد.
• Composite: کلاس فوق Collection ی از آبجکتها را در خود نگهداری می‌کند، به عبارتی در Composite می‌توان بخشی از ساختار درختی را قرار داد، که این ساختار می‌تواند ترکیبی از آبجکتهای Leaf و Composite باشد. در مثال File و Folder، یک Folder را می‌توان به عنوان Composite در نظر گرفت،زیرا که یک Folder می‌تواند چندین File یا Folder را در خود جای دهد. در کلاس Composite معمولا متدهایی همچون Add (افزودن Remove،( Child (حذف یک Child) و غیرو... وجود دارد. 

public interface Icomponent
    {
        void Display(int depth);
    }

 public class Leaf:Icomponent
    {
        private String name = string.Empty;
        public Leaf(string name)
        {
            this.name = name;
        }

        public void Display(int depth)
        {

            Console.WriteLine(new String('-', depth) + ' ' + name);

        }
    }

 public class Composite:Icomponent
    {
        private List<Icomponent> _children = new List<Icomponent>();
        private String name = String.Empty;

        public Composite(String sname)
        {
            this.name = sname;
        }

        public void Add(Icomponent component)
        {

            _children.Add(component);

        }


        public void Remove(Icomponent component)
        {

            _children.Remove(component);

        }


        public void Display(int depth)
        {

            Console.WriteLine(new String('-', depth) + ' ' + name);



            // Recursively display child nodes

            foreach (Icomponent component in _children)
            {

                component.Display(depth + 2);

            }

        }
    }

class Program
    {
        static void Main(string[] args)
        {
            // Create a tree structure

            Composite root = new Composite("root");

            root.Add(new Leaf("Leaf A"));

            root.Add(new Leaf("Leaf B"));



            Composite comp = new Composite("Composite X");

            comp.Add(new Leaf("Leaf XA"));

            comp.Add(new Leaf("Leaf XB"));



            root.Add(comp);

            root.Add(new Leaf("Leaf C"));



            // Add and remove a leaf

            Leaf leaf = new Leaf("Leaf D");

            root.Add(leaf);

            root.Remove(leaf);



            // Recursively display tree

            root.Display(1);

            Console.ReadKey();
        }
    }

به بخش modules درIIS بروید. در پنل سمت راست همه امکانات جهت افزودن و ویرایش و حذف وجود دارند:

روش معرفی ماژول در خط فرمان با استفاده از دستور Appcmd

 Appcmd.exe install module   /name:MODULE_NAME /image:PATH_TO_DLL

قسمت name که نام ماژول است  و قسمت image هم مسیر قرار گرفتن فایل dll هست.

برای نمونه:

%windir%\system32\inetsrv\appcmd.exe install module /name:DefaultDocumentModule /image:%windir%\system32\inetsrv\defdoc.dll

در صورتیکه ماژولی که قبلا افزوده شده باشد را بخواهید اضافه کنید، خطای زیر را دریافت خواهید کرد:

ERROR ( message:Failed to add duplicate collection element "DefaultDocumentModule". )

جهت حذف ماژول دستور زیر را صادر کنید:

Appcmd.exe uninstall module MODULE_NAME

نمونه:

%windir%\system32\inetsrv\appcmd.exe uninstall module DefaultDocumentModule

گرفتن کوئری یا لیستی از ماژول‌های فعال برای یک اپلیکیشن یا عمومی:

Appcmd.exe list modules [/app.name:APPLICATION_NAME]

سوپپچ aap.name اختیاری است ولی اگر نام یک اپلیکیشن را به آن بدهید، فقط ماژول‌هایی را که روی این اپلیکیشن اجرا می‌شوند، لیست می‌کند.

نمونه:

%windir%\system32\inetsrv\appcmd.exe list modules /app.name:"Default Web Site"

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

%windir%\system32\inetsrv\appcmd.exe list modules

خط زیر یک ماژول را برای همه اپلیکیشن‌ها یا اپلیکیشن خاصی فعال می‌کند که بستگی دارد سوییچ type چگونه مقداردهی شده باشد:

Appcmd.exe add module /name:MODULE_NAME /type:MGD_TYPE

برای مثال خط زیر باعث می‌شود ماژول Forms Authentication فقط برای وب اپلیکیشن default web site فعال شود:

%windir%\system32\inetsrv\appcmd.exe add module /name:FormsAuthentication /type:System.Web.Security.FormsAuthenticationModule /app.name:"Default Web Site"

یا در پایین آن را به صورت عمومی یا global فعال می‌کند:

%windir%\system32\inetsrv\appcmd.exe add module /name:FormsAuthentication /type:System.Web.Security.FormsAuthenticationModule

برای غیرفعال کردن یک ماژول از دستور زیر استفاده می‌شود:

Appcmd.exe delete module MODULE_NAME [/app.name:APPLICATION_NAME]

اگر غیر فعال کردن یک ماژول در یک اپلیکیشن خاص مدنظر شما باشد دستور زیر نمونه آن است:

%windir%\system32\inetsrv\appcmd.exe delete module FormsAuthentication /app.name:"Default Web Site"

اگر قصد دارید آن‌را بر روی تمامی اپلیکیشن‌ها غیرفعال کنید، دستور زیر نمونه آن است:

%windir%\system32\inetsrv\appcmd.exe delete module FormsAuthentication

حفظ کردن یا به خاطر سپردن دستورات بالا ممکن است کار سخت و دشواری باشد، به همین جهت از help کمک بگیرید:

Appcmd.exe module /?

یا به شکل اختصاصی‌تر برای یک دستور

Appcmd.exe install module /?Appcmd add module /?

namespace Microsoft.Extensions.DependencyInjection
{
    public interface IServiceCollection : 
       ICollection<ServiceDescriptor>, IEnumerable<ServiceDescriptor>,
       IEnumerable, IList<ServiceDescriptor>
    {
    }
}

ServiceProvider و مؤلفه‌های درونی آن، از یک مجموعه از ServiceDescriptor‌ها برای برنامه‌ی شما بر اساس سرویس‌های ثبت شده‌ی توسط IServiceCollection استفاده می‌کنند. ServiceDescriptor حاوی اطلاعاتی در مورد سرویس‌های ثبت شده‌است. اگر به کد منبع این کلاس برویم، می‌بینیم پنج Property اصلی دارد که با استفاده از آن‌ها اطلاعات یک سرویس ثبت و نگهداری می‌شوند. با استفاده از این  اطلاعات در هنگام اجرا ، DI Container به واکشی و ساخت نمونه‌هایی از سرویس درخواستی اقدام می‌کند:

public Type ImplementationType { get; }
public object ImplementationInstance { get; }
public Func<IServiceProvider, object> ImplementationFactory { get; }
public ServiceLifetime Lifetime { get; }
public Type ServiceType { get; }

هر کدام از این Property ‌ها کاربرد خاص خود را دارند:

• · ServiceType : نوع سرویسی را که می‌خواهیم ثبت شود، مشخص می‌کنیم ( مثلا اینترفیس IMessageService ) .  
• · ImplementionType : نوع پیاده سازی سرویس مورد نظرمان را مشخص می‌کند ( مثلا کلاس MessageService ).  
• · LifeTime : طول حیات سرویس را مشخص می‌کند. DI Container بر اساس این ویژگی، اقدام به ساخت و از بین بردن نمونه‌هایی از سرویس می‌کند.  
• · ImplementionInstance : نمونه‌ی ساخته شده‌ی از سرویس است.  
• · ImplementionFactory : یک Delegate است که چگونگی ساخته شدن یک نمونه از پیاده سازی سرویس را در خود نگه می‌دارد. این Delegate یک IServiceProvider را به عنوان ورودی دریافت می‌کند و یک object را بازگشت می‌دهد.

به صورت عادی، در سناریوهای معمول ثبت سرویس‌ها درون IServiceCollection، نیازی به استفاده از ServiceDescriptor نیست؛ ولی اگر بخواهیم سرویس‌ها را به روش‌های پیشرفته‌تری ثبت کنیم، مجبوریم که به صورت مستقیم با این کلاس کار کنیم.

می توانیم یک ServiceDesciriptor را به روش‌های زیر تعریف کنیم:

var serviceDescriptor1 = new ServiceDescriptor(
   typeof(IMessageServiceB),
   typeof(MessageServiceBB),
   ServiceLifetime.Scoped);

var serviceDescriptor2 = ServiceDescriptor.Describe(
   typeof(IMessageServiceB),
   typeof(MessageServiceBB),
   ServiceLifetime.Scoped);

var serviceDescriptor3 = ServiceDescriptor.Singleton(typeof(IMessageServiceB), typeof(MessageServiceBB));

var serviceDescriptor4 = ServiceDescriptor.Singleton<IMessageServiceB, MessageServiceBB>();

همانطور که دیدیم، IServiceCollection در واقع لیست و مجموعه‌ای از اشیاء است که از نمونه‌های جنریک IServiceCollection ، IList ، IEnumerable و Ienumberabl ارث بری می‌کند؛ بنابراین می‌توان از متدهای تعریف شده‌ی در این اینترفیس‌ها برای IServiceCollection نیز استفاده کرد. حالا ما برای اضافه کردن این سرویس‌های جدید، بدین طریق عمل می‌کنیم:

Services.Add(serviceDescriptor1);

استفاده از متدهای TryAdd() 

به کد زیر نگاه کنید :

services.AddScoped<IMessageServiceB, MessageServiceBA>();
services.AddScoped<IMessageServiceB, MessageServiceBB>();

برای جلوگیری از این خطا می‌توانیم از متدهای TryAddSingleton() ، TryAddScoped() و TryAddTransient() استفاده کنیم. این متدها درون فضای نام Microsoft.Extionsion.DependencyInjection.Extension قرار دارند.

عملکرد کلی این متدها درست مثل متد‌های Add() است؛ با این تفاوت که این متد ابتدا IServiceCollection را جستجو می‌کند و اگر برای type مورد نظر سرویسی ثبت نشده بود، آن را ثبت می‌کند:

services.TryAddScoped<IMessageServiceB, MessageServiceBA>();
services.TryAddScoped<IMessageServiceB, MessageServiceBB>();

جایگذاری یک سرویس با نمونه‌ای دیگر

گاهی اوقات می‌خواهیم یک پیاده سازی دیگر را بجای پیاده سازی فعلی، در DI Container ثبت کنیم. در این حالت از متد Replace() بر روی IServiceCollection برای این کار استفاده می‌کنیم. این متد فقط یک ServiceDescriptor را به عنوان پارامتر ورودی می‌گیرد:

services.Replace(serviceDescriptor3);

services.RemoveAll<IMessageServiceB>();

معمولا در پروژه‌های معمول خودمان نیازی به استفاده از Replace() و RemoveAll() نداریم؛ مگر اینکه بخواهیم پیاده سازی اختصاصی خودمان را برای سرویس‌های درونی فریم ورک یا کتابخانه‌های شخص ثالث، بجای پیاده سازی پیش فرض، ثبت و استفاده کنیم.  

AddEnumerable()

فرض کنید دارید برنامه‌ی نوبت دهی یک کلینیک را می‌نویسید و به صورت پیش فرض از شما خواسته‌اند که هنگام صدور نوبت، این قوانین را بررسی کنید:

•   هر شخص در هفته نتواند بیش از 2 نوبت برای یک تخصص بگیرد.
•   اگر شخص در ماه بیش از 3 نوبت رزرو شده داشته باشد ولی مراجعه نکرده باشد، تا پایان ماه، امکان رزرو نوبت را نداشته باشد .
•   تعداد نوبت‌های ثبت شده‌ی برای پزشک در آن روز نباید بیش از تعدادی باشد که پزشک پذیرش می‌کند.
•   و ...

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

•   نوبت‌های ثبت شده برای یک شخص نباید دارای تداخل باشند.

در این حالت ما باید دوباره سرویس Register را باز کنیم و به متد بررسی کردن قوانین برویم و دوباره کدهایی را برای بررسی کردن قانون جدید بنویسیم و احتمالا کد ما به این صورت خواهد شد:

public class RegisterAppointmentService : RegisterAppointmentService
{
  public Task<Result> RegisterAsync(
    PatientInfoDTO patientIfno , DateTimeOffset requestedDateTime ,
    PhysicianId phusicianId )
  {
      CheckRegisterantionRule(patientInfo);
      // code here
  }

  private Task CheckRegisterationRule(PatientInfoDTO patientInfo)
  {
       CheckRule1(patientInfo);
       CheckRule2(patientInfo);
       CheckRule3(patientInfo);
  }
}  
 

در این حالت باید به ازای هر قانون جدید، به متد CheckRegisterationRule برویم و به ازای هر قانون، یک متد private جدید را بسازیم. مشکل این روش این است که در این حالت ما مجبوریم با هر کم و زیاد شدن قانون، این کلاس را باز کنیم و آن را تغییر دهیم و با هر تغییر دوباره، تست‌های واحد آن را دوباره نویسی کنیم. در یک کلام در کد بالا اصول Separation of Concern و  Open/Closed Principle را رعایت نمی‌شود.

یک راهکار این است که یک سرویس جداگانه را برای بررسی کردن قوانین بنویسیم و آن را به سرویس ثبت نوبت تزریق کنیم:

public class ICheckRegisterationRuleForAppointmentService : ICheckRegisterationRuleForAppointmentService
{
     public Task CheckRegisterantionRule(PatientInfoDTO patientInfo)
     {
                CheckRule1(patientInfo);
                CheckRule2(patientInfo);
                CheckRule3(patientInfo);
      }
}

public class RegisterAppointmentService : IRegisterAppointmentService
{
  private ICheckRegisterationRuleForAppointmentService  _ruleChecker;
 
  public RegisterAppointmentService (RegisterAppointmentService  ruleChecker)
  {
          _ruleChecker = ruleChecker;  
  }

  public Task<Result> RegisterAsync(
     PatientInfoDTO patientIfno , 
     DateTimeOffset requestedDateTime , 
     PhysicianId phusicianId )
  {
             _ruleChecker.CheckRegisterantionRule(patientInfo);
                // code here
  }
}

با این کار وظیفه‌ی چک کردن قوانین و وظیفه‌ی ثبت و ذخیره سازی قوانین را از یکدیگر جدا کردیم؛ ولی همچنان در سرویس بررسی کردن قوانین، اصل Open/Closed رعایت نشده‌است. خب راه حل چیست !؟

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

interface IAppointmentRegisterationRule
{
  Task CheckRule(PatientInfo patientIfno);
}

public class AppointmentRegisterationRule1 : IAppointmentRegisterationRule
{
      public Task CheckRule(PatientInfo patientIfno)
      {
          Console.WriteLine("Rule 1 is checked");
          return Task.CompletedTask;
      }
}

public class AppointmentRegisterationRule2 : IAppointmentRegisterationRule
{
     public Task CheckRule(PatientInfo patientIfno)
     {



          Console.WriteLine("Rule 2 is checked");
          return Task.CompletedTask;
     }
}

public class AppointmentRegisterationRule3 : IAppointmentRegisterationRule
{
      public Task CheckRule(PatientInfo patientIfno)
      {
           Console.WriteLine("Rule 3 is checked");
           return Task.CompletedTask;
      }
}

public class AppointmentRegisterationRule4 : IAppointmentRegisterationRule
{
      public Task CheckRule(PatientInfo patientIfno)
      {
          Console.WriteLine("Rule 4 is checked");
          return Task.CompletedTask;
      }
}

services.AddScoped<IAppointmentRegisterationRule, AppointmentRegisterationRule1>();
services.AddScoped<IAppointmentRegisterationRule, AppointmentRegisterationRule2>();
services.AddScoped<IAppointmentRegisterationRule, AppointmentRegisterationRule3>();
services.AddScoped<IAppointmentRegisterationRule, AppointmentRegisterationRule4>();

public class CheckRegisterationRuleForAppointmentService : ICheckRegisterationRuleForAppointmentService
{
       private IEnumerable<IAppointmentRegisterationRule> _rules ;

       public CheckRegisterationRuleForAppointmentService(IEnumerable<IAppointmentRegisterationRule> rules)
       {
           _rules = rules;
       }

      public Task CheckRegisterantionRule(PatientInfoDTO patientInfo)
      {
          foreach(var rule in rules)
          {
                rule.CheckRule(patientInfo);
          }
      }
}

 کد بالا به نظر کامل می‌آید ولی مشکلی دارد! اگر در DI Container برای IAppointmentRegisterationRule یک قانون را دو یا چند بار ثبت کنیم، در هر بار بررسی کردن قوانین، آن را به همان تعداد بررسی می‌کند و اگر این فرآیند منابع زیادی را به کار می‌گیرد، می‌تواند عملکرد برنامه‌ی ما را به هم بریزد.  برای جلوگیری از این مشکل، از متد TryAddEnumerabl() استفاده می‌کنیم که لیستی از ServiceDescriptor ‌ها را می‌گیرد و هر serviceDescriptor را فقط یکبار ثبت می‌کند:

services.TryAddEnumerable(new[] {
  ServiceDescriptor.Scoped(typeof(IAppointmentRegisterationRule), typeof(AppointmentRegisterationRule1)),
  ServiceDescriptor.Scoped(typeof(IAppointmentRegisterationRule), typeof(AppointmentRegisterationRule2)),
  ServiceDescriptor.Scoped(typeof(IAppointmentRegisterationRule), typeof(AppointmentRegisterationRule3)),
  ServiceDescriptor.Scoped(typeof(IAppointmentRegisterationRule), typeof(AppointmentRegisterationRule4)),
});

[Entity]
    public interface IBook
    {
        [Identifier]
        string Id { get; }

        string Title { get; set; }

        string Isbn { get; set; }
    }

DatabaseContext context = new DatabaseContext();    
  context.Books.Add(new Book());

public interface IUnitOfWork
    {
        BrightstarEntitySet<T> Set<T>() where TEntity : class;
        void DeleteObject(object obj); 
         void SaveChanges();
    }