Dogevents – VS2017, Nunit, Separacja modelu domenowego

Opublikowano przez

Kolejny raport z pola walki 😈
Dziś kilka słów o nowym Visual Studio 2017, jak porzuciłem (chwilowo) NUnit oraz modelu domenowym, jego strukturze i separacji.

VS2017

Wczoraj instalowałem pierwszy update, który sporo poprawił w zakresie dodawania referencji do projektów. Do tej pory po dodaniu referencji do projektu musiałem robić restart solucji żeby zmiany zostały zauważone. Często VS gubił nawet referencje do System namespace – sick! Ale to zapewne takie małe uciążliwości wieku niemowlęcego 😋

NUnit

Dotychczas korzystałem z NUnit i w tym projekcie także chciałem go wykorzystać. Spędziłem 2h na próbie konfiguracji z .net core po czym ten błąd pogrzebał moje nadzieję. Does not work after migrating to csproj. Zaciągnąłem do pracy xUnit – przy okazji coś nowego się nauczę.

Separacja modelu domenowego

Mój projekt w głównej mierze polega na danych dostarczonych z Facebook API. Tak pobrane dane są  przetwarzane i zapisywane w bazie danych.

Trzy elementy – Facebook API, która zwraca swój model danych, warstwa domeny biznesowej, która je przetwarza oraz warstwa bazy danych, która je utrwala. W swoim projekcie zacząłem od zaprojektowania modelu domenowego (domain model), który jednocześnie stał się modelem bazy danych (persistence model). Co z tego wynikło i jaki są wady i zalety takiego podejścia?

Pierwsze wrażenie

Prostota. Jedna klasa, którą operuje w na poziomie logiki biznesowej i dostępu do danych. 

Jednak po kilku testach okazało się, że ta wspólna zależność ma swoje wady. Jakakolwiek zmiana tego modelu „psuje” dostęp do danych – głównie poprzez błędy deserializacji związane z brakiem jakiejś właściwości, która została usunięta czy jej nazwa zmieniona. Musiałem czyścić kolekcje w mongodb i zaczynać od nowa wrzucać dane. W początkowym etapie nie jest to dla mnie problemem ale z czasem może być upierdliwe kiedy dokonujemy sporych zmian. Sam mongodb driver posiada pewne mechanizmy, konwencje, które pozwalają sobie z tym radzić.

Dzielić czy nie dzielić

Po tym etapie rozmyślałem nad wprowadzeniem separacji pomiędzy modelem domenowym i danych. Do mapowania użyć Automappera, czy własnych metod rozszerzających (extension methods). Pytanie czy to miałoby sens, jakie przyniosło by korzyści a jakie wady?

  • + Szybki start – jedna klasa, żadnych mapowań
  • – Model bazy danych silnie zależny od domenowego.
Ta zależność może najbardziej boleć. Model bazy danych może przechowywać wiele więcej informacji o innej strukturze niż domenowy i przypadkiem możemy udostępnić na poziomie logiki biznesowej dostęp do powiedzmy niepożądanych danych.
Polecam przeczytać post Having the domain model separated from the persistence model aby zgłębić wady i zalety różnych rozwiązań.
Ja zostałem przy „połączonym” modelu. Na chwilę obecną nie potrzebuję takiej separacji. Dodatkowe zagrożenie jest takie że moja klasa „Event” również odzwierciedla model zewnętrznego Facebook API. A jest to coś co nie jest zależne ode mnie i jeśli na tej warstwie zajdzie duża zmiana wpłynie ona bezpośrednio na mój model domenowy – a tego zdecydowanie należy uniknąć.