Komutun kendisinde yöntem yerine neden CommandHandler sınıfını Handle () ile ayırın

S # arp mimarisi kullanarak böyle uygulanan CQRS desen bir parçası var :

public class MyCommand
{
    public CustomerId { get; set; }

    // some other fields
}

public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult>
{
    Handle(MyCommand command)
    {
        // some code for saving Customer entity

        return CommandResult.Success;
    }
}

Neden sadece Commandveri ve işleme yöntemi içeren bir sınıf var merak ediyorum ? Komut işleme mantığını komut özelliklerinden ayrı olarak test etmeniz gereken bir tür test edilebilirlik avantajı mıdır? Yoksa, farklı uygulamalarla tek bir komuta sahip olmanız gereken sık sık bir iş gereksinimi mi var ICommandHandler<MyCommand, CommandResult>?

Komik, bu soru bana mühendislerimizden biriyle üzerinde çalıştığım iletişim kütüphanesi hakkında yaptığım aynı konuşmayı hatırlattı.

Komutlar yerine, Request sınıfları ve sonra RequestHandlers vardı. Tasarım, tanımladığınız şeye çok benziyordu. Sanırım sahip olduğunuz karışıklığın bir kısmı, İngilizce "komut" kelimesini görmeniz ve anında "fiil, eylem ... vb."

Ancak bu tasarımda, Komuta'yı (veya İsteği) bir mektup olarak düşünün. Veya posta hizmetinin ne olduğunu bilmeyenler için e-postayı düşünün. Basitçe içeriktir, bu içeriğin nasıl davranılması gerektiğinden ayrılmıştır.

Neden bunu yaptın? Çoğu basit durumda, Komut Deseni'nin bir nedeni yoktur ve bu sınıfın doğrudan iş yapmasını sağlayabilirsiniz. Bununla birlikte, tasarımınızdaki gibi ayrıştırmanın yapılması, eyleminizin / komutunuzun / isteğinizin biraz mesafe kat etmesi gerektiğinde mantıklıdır. Örneğin, soketler veya borular boyunca veya alan ve altyapı arasında. Ya da mimarinizde komutlarınızın kalıcı olması gerekir (örn. Komut işleyicisi, bazı sistem olayları nedeniyle 200 komut geldiğinde ve ilk 40 işlem kapatıldıktan sonra bir seferde 1 komut yapabilir). Bu durumda, basit bir salt mesaj sınıfına sahip olmak, sadece mesaj kısmını JSON / XML / ikili / herhangi bir şekilde serileştirmek ve komut işleyicisi işlemeye hazır olana kadar boru hattından geçirmek çok basit hale gelir.

Command'ı CommandHandler'dan ayırmanın başka bir avantajı, şimdi paralel miras hiyerarşisi seçeneğinizin olmasıdır. Örneğin, tüm komutlarınız serileştirmeyi destekleyen bir temel komut sınıfından türetilebilir. Ve belki de çok fazla benzerliğe sahip 20 komut işleyicisinden 4'üne sahipsiniz, şimdi bunları gelen işleyici temel sınıfından türetebilirsiniz. Eğer bir sınıfta veri ve komut yönetimi yapacak olsaydınız, bu tür bir ilişki hızla kontrolden çıkardı.

Ayrıştırma için başka bir örnek, komutunuz çok az girdi gerektiriyorsa (örneğin 2 tamsayı ve bir dize), ancak işleme mantığı, ara üye değişkenlerinde veri depolamak istediğiniz yerde yeterince karmaşıktı. 50 komutu kuyruğa alırsanız, tüm bu ara depolama için bellek ayırmak istemezsiniz, bu nedenle Command'ı CommandHandler'dan ayırırsınız. Şimdi 50 hafif veri yapısını kuyruğa alıyorsunuz ve daha karmaşık veri depolaması, komutları işleyen CommandHandler tarafından yalnızca bir kez (veya N işleyiciniz varsa N kez) ayrılıyor.

Normal komut düzeni , veri ve davranışın tek sınıfta olmasıyla ilgilidir. Bu tür 'Komut / İşleyici kalıbı' biraz farklıdır. Normal desene kıyasla tek avantaj, komutunuzun çerçevelere bağlı olmamasının avantajıdır. Örneğin, komutunuzun DB erişimine ihtiyacı olabilir, bu nedenle bir çeşit DB bağlamına veya oturumuna sahip olması gerekir, yani çerçevelere bağlıdır. Ancak bu komut alan adınızın bir parçası olabilir, bu nedenle Bağımlılık Ters Çevirme İlkesine göre çerçevelere bağımlı olmasını istemezsiniz . Giriş ve çıkış parametrelerini davranıştan ayırmak ve bunları bağlamak için bazı dağıtıcıya sahip olmak bunu düzeltebilir.

Öte yandan, hem mirasın hem de komutların kompozisyonunun avantajını kaybedeceksiniz. Bence bu gerçek güç.

Ayrıca, küçük nitpick. Command adında olması onu CQRS'nin bir parçası yapmaz. Bu çok daha temel bir şeyle ilgili. Bu tür yapı aynı anda hem komut hem de sorgu olarak kullanılabilir.