W poprzednim poście opisałem wzorzec repozytorium. Jak już wspomniałem, repozytorium może różnić się  implementacją w zależności od encji. W skrajnych przypadkach może być jedno repozytorium na jedną encję (Order – OrderRepository, Product – ProductRepository itp). Tworzenie każdego repozytorium ręcznie w zależności od przetwarzanej encji jest dość niewygodne. Przydałby się jakiś globalny mechanizm na tworzenie obiektów na podstawie typu encji.

Dobrym rozwiązaniem problemu jest implementacja wzorca service locator, wywodzącego się  z wzorca factory. Ogólnie mówiąc, factory jest to klasa z metodą Create odpowiedzialną za dynamiczną inicjalizację. Spójrzmy na diagram klas wzorca:

Jeśli diagram nie jeszcze jasny, przedstawiam dodatkowo szkic kodu:

public interface IWindowFactory
{
   IWindow Create();
}
public class WindowsXpWindowFactory : IWindowFactory
{
   public IWindow Create()
   {
       return new WindowXp();
   }
}

IWindow to interfejs okna. WindowXp, Window98 to okna stylizowane na konkretny system operacyjny. W rozważanym przykładzie, celem jest stworzenie klas, które umożliwiają nam podpinanie różnych skórek czy też kontrolek stylizowanych np. na system operacyjny. W standardowym podejściu, użytkownik w celu stworzenia okna, wykonuje po prostu:

WindowXp window = new WindowXp();

Podejście ma zasadniczą wadę – co w przypadku gdy chcemy zmieniać skórki w czasie działania programu? Za pomocą wzorca factory, programista tworzyłby okna w następujący sposób:

IWindow window = windowFactory.Create();

W zależności od wstrzykniętego factory, okno stylizowane na jakiś system zostanie utworzone.

Można oczywiście stworzyć więcej klas factory. Przykładowo,  jeśli piszemy testy jednostkowe można stworzyć klasę WindowStubFactory, która będzie zwracać stuby\mocki zamiast rzeczywistych obiektów. Ponadto obiekty tworzone (tutaj okna) mogą posiadać wyłącznie konstruktor z modyfikatorem internal – dzięki temu użytkownik biblioteki będzie zmuszony do wykorzystania factory aby stworzyć dany obiekt. Jeśli ktoś jest zainteresowany dokładniejszym opisem wzorca, polecam książkę “Design Patterns, Elements of Reusable Object-Oriented Software”.

Service locator tak naprawdę nie różni się znacząco od factory. Jak sama nazwa wskazuje, zadaniem wzorca jest lokalizacja jakiś usług. W naszym przypadku będą lokalizowane repozytoria na podstawie typu encji:

public class RepositoryLocator
{
   private Dictionary<Type, IRepository> m_Repositories = null;
   public RepositoryLocator()
   {
       m_Repositories = new Dictionary<Type, IRepository>();
       m_Repositories.Add(typeof(Order),new OrderRepository());
       m_Repositories.Add(typeof(Product),new ProductRepository());
   }
   public IRepository GetForBusinessObject<T>(): where T : BusinessObject
   {
       return GetForBusinessObject(typeof(T));
   }
   public IRepository GetForBusinessObject(Type type)
   {
       if (m_Repositories.ContainsKey(type))
           return m_Repositories[type];
       else
           return null;
   }
}

Użytkownik chcąc stworzyć repozytorium dla danego obiektu biznesowego wywołuje:

RepositoryLocator locator = new RepositoryLocator();
IRepository orderRepository=locator.GetForBusinessObject<Order>();
IRepository productRepository=locator.GetForBusinessObject<Product>();

Implementując warstwę biznesową za pomocą DomainModel lub ActiveRecord uzyskujemy bardzo rozdrobniony interfejs. Ponadto stworzone obiekty biznesowe zawierają logikę odnoszącą się tylko do konkretnej encji. W poprzednich postach pokazałem prostą klasę Client, implementującą wzorzec DomainModel. Przedstawiona klasa mogła wykonywać tylko operacje dla konkretnego, jednego klienta. W systemie jednak często będziemy musieli brać pod uwagę zbiór encji. Przykładowo może być potrzeba zwrócenia zbioru klientów, dla których suma dokonanych zamówień przekracza jakąś wartość. Ponadto analizując wzorce DM oraz AR łatwo zauważyć, że nie ma tam metod wstawiania nowych encji do bazy danych. Rozwiązaniem na przedstawione problemy jest wzorzec repozytorium. Zawiera on przede wszystkim operacje CRUD (Create, Read, Update, Deleted) oraz wszystkie inne operacje selekcji (np. GetById lub GetByQuery ). Przeważnie definiuje się jedno repozytorium na jeden obiekt biznesowy. Bardzo ważną cechą repozytorium jest niezależność od bazy danych. Użytkownik powinien korzystać z poprawnie zaimplementowanego repozytorium jak ze zwyklej klasy czy kolekcji danych. Dlatego dobrym zwyczajem jest stworzenie najpierw interfejsu a dopiero potem konkretnej klasy (implementacji):

public interface IClientRepository
{    
    Client GetById(Guid id);   
    Client GetByQuery(Query query);
    void Add(Client client);
    void Remove(Client client);
    void Update(Client client);    
        
    /*Inne specyficzne metody dla obiektu "Client".
      Może być to np. wyszukiwanie klientów po sumie zamówien,
      regionie pochodzenia, kupowanych towarach itp.
    */ 

}

Warto zauważyć, że większość metod w każdym repozytorium będzie się powtarzać. Operacje typu CRUD będzie zawierać zarówno repozytorium Client jak i każde inne. Z tego względu lepszym rozwiązaniem jest wprowadzenie generycznego interfejsu bazowego:

public interface IRepository<T>
{
    T GetById(Guid id);   
    T GetByQuery(Query query);
    void Add(T item);
    void Remove(T item);
    void Update(T item);    
}

Jeśli jakieś repozytorium musi zawierać metody niestandardowe to po prostu rozszerza interfejs:

public interface IOrderRepository:IRepository<Order>
{
    Order[] GetOrdersByClientId(Guid idClient);
}

Dobry zwyczajem jest również niezależność konkretnych implementacji repozytorium od bazy danych np:

public class OrderRepository:IOrderRepository)
{
    private IDataContext m_DataContext=null;
    public OrdeRepository()
    {
       // inicjalizacja m_DataContext
    }
    public void Add(Order item)
    {
       m_DataContext.Add(item);
    }
    ...
}

W powyższym przykładzie operacje związane z fizycznym zapisem w bazie danych przekazywane są do klasy z warstwy DAL. Ponadto konkretna implementacja IDataContext może być wstrzykiwana nawet w trakcie działania programu. W końcu jeśli chcemy zawrzeć w repozytorium logikę biznesową, nie ma mowy o jakiejkolwiek zależności klasy z bazą danych – repozytorium jest abstrakcyjne w przeciwieństwie do podobnych rozwiązań z DAL.

Wyobraźmy sobie, że założenia projekty wymagały implementacji repozytorium dla każdego obiektu biznesowego. Powstaje więc pytanie, w jaki sposób wygodnie tworzyć instancję repozytorium dla konkretnego obiektu biznesowego? Nie chcemy w kodzie operować wyłącznie na konkretnych klasach tzn:

OrderRepository orderRepository = new OrderRepository();
ProductRepository productRepository = new ProductRepository();
ClientRepository orderRepository = new ClientRepository();

Lepszym rozwiązaniem jest wykorzystywanie ogólnych interfejsów (np. IRepository). W następnym poście postaram się odpowiedzieć na te pytanie przedstawiając kilka dodatkowych wzorców projektowych (m.in factory, service locator).

Oczywiście nie ma jednoznacznej odpowiedzi jaki wzorzec używać. Wszystko zależy od konkretnych wymagań aplikacji oraz dostępnego czasu na ukończenie projektu. Wzorce obiektowe na pewno cechują się większą elastycznością od wzorców proceduralnych. Z drugiej strony jeśli projekt nie jest zbyt skomplikowany to po co poświęcać czas na implementacje ich, jeżeli i tak to w przyszłości nie zwróci się (w postaci zaoszczędzonego czasu)?

Generalnie im więcej poświecimy czasu  na początku na implementacje wzorca tym oszczędności będą większe podczas przyszłych rozszerzeń systemu.
W poście chciałbym stworzyć krótkie porównanie wzorców na podstawie pewnych kryteriów, które uznałem za istotne:

1. Skalowalność – określa jak łatwo system radzi sobie ze wzrastającą liczbą użytkowników.System można skalować poprzez wprowadzenie dodatkowych usług sieciowych czy rozproszonych baz danych . W przypadku skryptu transakcji, aktywnego rekordu i modułu tabeli skalowalność jest ograniczona ponieważ wzorce są mocną zorientowane na bazę danych. Z kolei model dziedziny bardzo dobrze z tym sobie poradzi ponieważ jego główna ideą jest oddzielenie logiki od źródła danych – sam wzorzec nie nakłada żadnych ograniczeń na warstwę persystencji.
2. Modularność – dobry program podzielony jest na pewne logiczne części, często niezależne od siebie.W przypadku wzorca TS ciężko mówić o jakiejkolwiek modularności. Często cała logika biznesowa składa się z jednej klasy. W przypadku modułu tabeli sytuacja wygląda nieco lepiej ponieważ zasady wzorca mówią już o pewnym podziale problemu na obiekty – nadal jednak jest to za mało aby uznać zbudowany system za modularny. Aktywny rekord z reguły jest modularny ponieważ występuje tam jawny podział na obiekty. AR wyklucza użytkowanie technik programowania obiektowego takich jak np. polimorfizm. Dlatego też  DM uznawany jest za najbardziej modularny wzorzec.
3. Testowalność – głównym wyzwaniem moim zdaniem są testy integracyjne, które wymagają rozdzielenia całości na fragmenty. Testy integracyjne wymagają wprowadzenia tzw. obiektów mock. Są to obiekty, które po prostu naśladują działanie prawdziwych obiektów. Powiedzmy, że mamy klasę Order, która wykonuje zaawansowaną logikę. Obiekt mock mógłby wyglądać następująco:

   public class OrderMock:Order
   {
       public override int GetDiscount()
       {
           return 20;
       }
       public override bool HasCredit()
       {
           return true;
       }
   }

   Jak widać klasa nie robi nic ciekawego, zwraca na sztywno jakiś wynik (często dynamicznie definiowany). Co nam to daje? Otóż klasa ma jedną wielką zaletę – nie robi nic konkretnego a zatem nie zawiera żadnych błędów. Testy integracyjne mają za zadanie przetestowanie całości systemu razem z połączeniami między modułami. Jeśli byśmy próbowali przetestować całość systemu od razu to w momencie wystąpienia błędu ciężko byłoby powiedzieć gdzie dokładnie wystąpił błąd. Z kolei jeśli zaczniemy testować pojedynczy moduł a resztę klas zastąpimy mockami, w razie błędu wiemy gdzie go szukać dokładnie. Następnie stopniowo będziemy podmieniać obiekty mock na te prawdziwe. Gdyby jakiś test nie poszedłby pozytywnie, wiemy, że prawdopodobnie przyczyna leży w nowo doczepionym węźle.

   Kryterium  zatem jest ściśle powiązane z modularnością opisaną powyżej. Skrypt transakcji oraz moduł tabeli ciężko zastąpić mock’iem. Aktywny rekord co prawda jest modularny ale przeważnie generowany jest automatycznie przez narzędzia ORM i często ciężko przeładować zachowanie dynamicznie wygenerowanych metod i właściwości (ponieważ nie są np. one wirtualne).

4. Scentralizowany system monitoringu oraz wykonywania logów. W systemie enterprise, wszelkie wystąpienie wyjątków musi być dokładnie odnotowane. Często strategie przechwytywania i zapisywania wyjątków są wstrzykiwane dynamicznie. Nie korzysta się więc ze standardowego bloku try-catch. Przeważnie istnieje klasa, którą wywołuje się w przypadku wystąpienia błędu. Skrypt transakcji ze względu na swoją budowę stanowi doskonałe miejsce na obsługę błędów. W przypadku pozostałych wzorców, prawdopodobnie będzie potrzeba wprowadzenie obsługi błędów w osobnej warstwie (w warstwie usług). Warto zwrócić uwagę na jeszcze jedno niebezpieczeństwo w przypadku DM. Często w niej korzystamy z wirtualnych metod. Użytkownik może zatem przeładować którąś z metod i zapomnieć wywołać metodę bazową, która odpowiedzialna jest za wykonanie odpowiedniego logu.
5. Wsparcie dla obiektów POCO. Skrypt transakcji oraz moduł tabeli wykonują odczyt bazy danych wewnątrz metod. Nie muszą być zatem oznaczone żadnymi atrybutami mówiącymi na jaką tabele dana klasa ma być zmapowana. Występuje wiec tu pełna zgodność z POCO. Podobnie sprawa wygląda z DM – wzorzec z definicji jest niezależny od źródła danych i musi być czystą klasą. Najgorzej prezentuje się aktywny rekord. Wszelkie ORM domyślnie generują obiekty niezgodne z POCO – oznaczone atrybutami lub dziedziczące po jakieś specjalnej klasie.Warto jednak podkreślić, że nHibernate czy Entity Framework wspierają POCO, z tym, że jest to po prostu niewygodne i wydaje mi się, że większość osób korzysta z domyślnie wygenerowanych klas przez EF.
6. Ograniczenia czasowe. Rozważając nad wyborem wzorca nie można zapomnieć oczywiście o deadline. Skrypt transakcji oraz moduł tabeli są oczywiście najprostszymi rozwiązaniami i nie wymagają dużej ilości czasu. Implementacja aktywnego rekordu jest również bardzo szybka o ile korzystamy  z narzędzia ORM – większość zrobi za nas dostarczony generator kodu.W przypadku DM sprawa wygląda kompletnie inaczej- ze względu na brak relacji jeden do jednego między obiektami biznesowymi a tabelą w bazie danych, narzędzia ORM nie mogą zrealizować mapowania automatycznie.

Na koniec tabela, przedstawiająca powyższe rozważania w liczbach (skala od 0 do 3):

Przyszedł czas na opisanie najbardziej złożonego wzorca warstwy biznesowej – modelu domeny (DM). Jeśli nie znacie dobrze wzorca opisanego w poprzednich postach (aktywny rekord) nie zaczynajcie nawet próbować zrozumieć DM ponieważ jest on po prostu rozszerzeniem AR.

Na początek kilka faktów. DM jest wzorcem w pełni obiektowym, wykorzystującym wszelkie dobrodziejstwa programowania obiektowego (dziedziczenie, polimorfizm itp.). DM w przeciwieństwie do AR nie jest wzorcem zorientowanym na bazę danych. Scenariusz wykorzystania AR często wyglądał tak, że programista tworzył najpierw bazę danych dla danego problemu biznesowego a dopiero potem obiekty biznesowe AR. W przypadku DM podejście wygląda zupełnie inaczej. Problem biznesowy kompletnie abstrahuje od bazy danych. Programista tworzy najpierw klasy rozwiązujące problem biznesowy a baza danych jest już potem tylko dodatkiem.

Podobnie jak AR, klasy DM przechowują informacje na poziomie wiersza. Przykładową klasą DM może być więc:

public class Client: Person
{
    public string FirstName {get;set;}
    public string LastName {get;set;}
    public abstract int GetDiscount();
}

Sama klasa wygląda tak jak AR. Jednak trzeba być świadomym kilku faktów:

1. Klasa nic nie wie o docelowej bazie danych. Obiekt takiej klasy po prostu reprezentuje kawałek logiki biznesowej. Kwestia zapisu jest już tylko sprawą techniczną i jak to zostanie zrobione nie należy to do kompetencji DM,
2. Klasa jest typu POCO. Klasy POCO muszą spełniać kilka warunków m.in nie mogą zawierać atrybutów czy  z góry narzuconych interfejsów zdefiniowanych przez ORM. Innymi słowy jest to po prostu czysta klasa c#,
3. Klasa Client dziedziczy po Person. Jest to jak najbardziej wskazane w DM,
4. Zawiera abstrakcyjną metodę – tak jak wspomniałem DM ze względu na pełną niezależność od bazy danych może wykorzystywać pełen zestaw dobrodziejstw programowania obiektowego,
5. Klasa Client nie musi odpowiadać jednej tabeli w bazie danych. Często pojedyncza klasa DM mapowana jest na wiele tabel. Występuje tu pełna niezależność ze względu na fakt, że zapisem do bazy nie zajmują się już obiekty biznesowe.

Zalety:

1. Zapobiega duplikacji logiki,
2. Rozłożenie problemu na obiekty biznesowej powoduje wzrost czytelności kodu,
3. Niezależność od źródła danych,
4. Obiekty są typu POCO, zatem mogą korzystać z rozszerzeń OOP,
5. Znacznie ułatwienia w wykonywaniu testów jednoskokowych ze względu na oddzielenie obiektów odo źródła danych.

Wady:

1. Bardzo czasochłonna implementacja,
2. Rozdrobniony interfejs,
3. Potrzeba wykorzystania dodatkowego wzorca (remote facade) w celu wyeksponowania logiki przez web service.

Nie będę pisać konkretnego kodu ponieważ wartość metod zależy już od budowanego systemu. Zamiast tego uważam, że lepszym wyjściem jest pokazanie diagramu klas. W końcu nie ważne co znajduje się w środku tylko jaka jest relacjami pomiędzy klasami. Poniżej krótki przykład DM w akcji dla systemu sprzedaży:

Dzisiaj przyszedł czas na pierwszy wzorzec obiektowy – aktywny rekord(AR). Zaczynamy od diagramu klas:

W przeciwieństwie do poprzednich wzorców, każda klasa definiuje fragment logiki biznesowej. Obiekty klas występują w relacji jeden do jednego względem wierszy w tabeli. Klasa Order będzie zawierała zatem logikę dla konkretnego zamówienia a nie dla zbioru zamówień. Klasy tworzymy zwykle dla każdej tabeli z bazy danych a ich instancje jak już wspomniałem dla każdego przetwarzanego wiersza.

Warto podkreślić, że środowisko .NET wspiera wzorzec aktywny rekord poprzez narzędzia ORM – Entity Framework czy LINQ to SQL. Przykładowa klasa warstwy biznesowej, zaimplementowana za pomocą aktywnego rekordu mogłaby wyglądać następująco:

public class Client
{
    public string FirstName {get;set;}
    public string LastName {get;set;}
    public string Email {get;set;}
    // logika biznesowa
    public int GetSubscriptionLevel()
    {
    }
    public int GetMaxCredit()
    {    
    }    
}

Zalety:

1. Prosta implementacja,
2. Solidne wsparcie środowisk programistycznych,
3. Zapobiega duplikacji logiki biznesowej,
4. Rozdzielenie problemu biznesowego na obiekty zwiększa czytelność kodu.

Wady:

1. Rozdrobnienie klas (podobnie jak w przypadku TM),
2. Wymaga wprowadzenia dodatkowej klasy w celu wyeksponowania danych przez usługę sieciową,
3. Wzorzec zbyt mocno zorientowany na bazę danych,
4. W przypadku gdy nie korzystamy z gotowych narzędzi ORM, implementacja wzorca jest bardzo skomplikowana i w takiej sytuacji znacznie lepiej zainteresować się wzorcem Domain Model.

Moduł tabeli (TM – table module) jest również wzorcem proceduralnym (podobnie jak TS). Rozwiązuje jednak podstawowy problem TS – brak zdefiniowania metody podziału logiki biznesowej na klasy. W przypadku TS sam wzorzec nie określał ile klas należy stworzyć. Wszystko zależało od programisty. Mógł on stworzyć jedną klasę zarządzającą zarówno zamówieniami jak i produktami. Moduł tabeli mówi po prostu, że należy stworzyć osobną klasę dla każdej tabeli w bazie danych. Czyli w przypadku gdy mamy tabele “Orders, Products, Invoices” będziemy potrzebować trzech klas TM. Warto jeszcze raz podkreślić, że wzorce proceduralne zarządzają całymi tabelami a nie pojedynczymi wierszami. Innymi słowy klasy TS lub TM dla zamówienia powinny być w następującej postaci:

public class OrderManager
{
    public void AddOrder(DataRow order)
    {
        // dodaj nowy wiersz do tabeli
    }
    public void RemoveOrder(Guid id)
    {
        // usuń wiersz o podanym ID
    }
    public DataRow GetOrderById(Guid id)
    {
        // znadź dany wiersz
    }    
}

a nie:

public class Order
{
    public DateTime OrderDateTime {get;set}
    public OrderItems[] OrderItems {get;set;}
    public Client Client {get;set;}
}

Pierwsza klasa jak widać zarządza całymi wierszami. Z kolei druga zawiera konkretne informacje dla pojedynczego wiersza.

Diagram klas wygląda bardzo podobnie jak diagram TS:

Na zakończenie standardowo przedstawiam zalety i wady, które uważam za istotne:

Zalety:

1. Prosta implementacja,
2. Zapobiega duplikacji logiki biznesowej poprzez jawny podział klas,
3. Podobnie jak w przypadku TS, środowiska programistyczne ułatwiają jego implementacje (np. poprzez klasy DataRow, bezpołączeniowy model dostępu do danych).

Wady:

1. Wzorzec zorientowany na dane – klasa tworzona na każdą tabele w bazie danych. Może to spowodować zbyt wielkie rozdrobnienie klas,
2. Ze względu na zbyt duże rozdrobnienie, wzorzec nie nadaje się bezpośrednio do wyeksponowania przez np. usługę sieciową. W przypadku TS często występuje tylko jedna klasa, która może bezpośrednio być wyeksponowana ponieważ stanowi ona tak naprawdę implementację wzorca “remote facade”,
3. Wzorzec moim zdaniem jest dość niewygodny w użyciu w przypadku zaawansowanych środowisk programistycznych, wspierających narzędzia typu ORM. Dzisiaj dla średnich projektów znacznie łatwiej użyć wzorca aktywny rekord (opiszę go w następnym poście).