wtorek, 21 marca 2017

Dogevents - VS2017, Nunit, Separacja modelu domenowego

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膮膰.

Brak komentarzy:

Prze艣lij komentarz