Jednym z wcześniejszych postów przedstawiłem aplikację nDepend obliczającą przeróżne metryki kodu. Większość metryk obliczanych przez program jest oczywista (liczba linii kodu, procent komentarzy, liczba klas itp). Na solidny komentarz zasługuje jednak złożoność cyklomatyczna (w skrócie CC). Aby obliczyć CC, należy najpierw należy narysować graf przepływu informacji dla badanego kodu. Złożoność można obliczać zarówno dla konkretnej metody jak i całego systemu. Rozpatrzmy następujący fragment kodu: priv...

Klasycznym sposobem mapowania DTO na obiekt biznesowy jest użycie wzorca projektowego adapter. Przykładowo aby zmapować Order do OrderDto możemy napisać następującą klasę:class OrderDtoAdapter { private Order mOrder =null; public OrderDtoAdapter(Order order) { mOrder = order; } publicvoid Initialize(Order orderDto) { orderDto.CreationDate = mOrder.CreationDate; orderDto.Client = mOrder.Client; orderDto.Id = m_Order.Id; } } Rozwiązanie całko...

Zwykle aplikacja potrzebuje spójnego UI - czyli kontrolek wyglądających i zachowujących się wg. ustalonego schematu. W programowaniu web mamy style css, asp.net ma mechanizm Control Adapters, WPF z tego co wiem także pozwala dość mocno ustandaryzować ten aspekt. W Windows Forms komercyjne pakiety kontrolek, jak np. Telerik, udostępniają możliwość swego rodzaju stylowania wyglądu kontrolek danego typu.

Autor: "Na początku przygody z Inversion of Control, a także dość długo później, moje wykorzystanie dostępnych kontenerów ograniczało się właściwie do ręcznego zarejestrowania wszystkich interfejsów, wszystkich interesujących mnie implementacji oraz zdefiniowaniu zależności w postaci parametrów konstruktora. Działało. Ostatnio korzystając z okazji postanowiłem podejść do problemu inaczej. Moim celem było zminimalizowanie czynności prowadzących do uzyskania żądanego efektu - "minimum friction development...

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 serv...

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, d...

Niedawno natknąłem się na StackOverflow interesujące pytanie dotyczące Domain-Driven Design. Chciałbym się z Wami podzielić moimi przemyśleniami. Pytanie dotyczyło zaprojektowania logiki biznesowej dla domeny składającej się z trzech obiektów: Książki (Book), Rozdziału (Chapter) oraz Strony (Page): Problem polega na tym, który element, z przedstawionych trzech, powinien być korzeniem agregatu?

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 t...

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. Scen...

Najprostszym wzorcem projektowym warstwy biznesowej,  należącym do grupy wzorców proceduralnych jest skrypt transakcji (w skrócie TS – transcaction script). Spójrzmy na diagram UML przedstawiający przykład jego użycia: Innymi słowy, TS jest zapisem przypadków użycia w naszym systemie. W przypadku systemu sprzedaży oczywistymi przypadki użycia są m.in.: dodanie nowego klienta do bazy, złożenie zamówienia czy pobranie listy produktów. Jak już wspomniałem jest to wzorzec proceduralny a nie obiektowy zate...