Utils - nowy moduł we frameworku

Tym razem wpis o bieżących postępach w pracy nad Pizzą. Jedną z głównych refaktoryzacji, które planowałem już od dawna było usunięcie zależności między Pizza.Mvc a Pizza.Framework. Rozdzielenie tych modułów wymaga kilku etapów pracy, ten post jest o pierwszym z nich - wydzieleniu przestrzeni nazw Pizza.Framework.Utils do nowego assembly Pizza.Utils.dll.

Tu jakby nie ma wielkiej filozofii, to co musiałem zrobić, to:

  1. Utworzyć nowy projekt typu Class Library. (Tak przy okazji - czy ktoś jest w stanie racjonalnie wytłumaczyć, czemu w Visual Studio szablon tego typu projektów znajduje się w sekcji Windows?)
  2. Przenieść do niego klasy.
  3. Następnie PPM na projekcie -> Refactor -> Adjust namespaces, aby Resharper ładnie dopasował przestrzenie nazw do folderów.

Następnie posprzątałem trochę w przestrzeni ValueInjection, tzn. publiczne API zostawiłem w głównym katalogu, a wszystkie konwencje przeniosłem do nowoutworzonego katalogu CustomInjections i ustawiłem im modyfikator internal.

Co mnie cieszy, to fakt, że mój skrypt Fake od razu załapał nowy moduł i zrobił z niego paczkę. Jest tak dobrze, jak miało być. :)

No i co z tego?

W sumie nic wielkiego nie zrobiłem, ale ważniejsze jest to, co zauważyłem przy okazji. Otóż - naszło mnie kilka wątpliwości, co do zawartości modułu Pizza.Framework:

  1. Przestrzeń nazw DataGeneration - zawiera rzeczy potrzebne jedynie przy testach i inicjalizowaniu aplikacji. To raczej nie powinno być w głównym module, więc prawdopodobnie przeniosę do oddzielnego.
  2. Przestrzeń nazw Persistence.Config - zawiera konfigurację automapowania i konwencje NHibernate. To jedyna konfiguracja zewnętrznych narzędzi trzymana w tym module. Pozostałe klasy tej biblioteki coś robią, te tylko konfigurują. Na domiar złego, ta konfiguracja sprawia, że Pizza prawdopodobnie współpracuje jedynie z MSSQL Serverem - bo w konwencjach są użyte są specyficzne typy danych. To również prawdopodobnie należy wydzielić do oddzielnego modułu. Zwłaszcza, jeśli faktycznie trzeba będzie implementować oddzielne konfiguracje dla różnych serwerów baz danych.
  3. Security - różne typy z tym związane są rozsiane po wszystkich modułach Pizzy. Niby to dobrze, bo przecież do realizacji uwierzytelniania i autoryzacji potrzebne są różne warstwy aplikacji, ale z drugiej strony, mam wrażenie, że to wprowadza trochę zamieszania. Ładne bazowe klasy frameworkowe, i nagle bach - specyficzna implementacja wymagania pozafunkcjonalnego. Coś mi tu śmierdzi, jeszcze nie wiem co dokładnie, i nie wiem co z tym zrobić.

Przy okazji odkryłem buga w kontrolce daty. Robi się ciekawie, trzeba będzie zwolnić testerów.

dajsiepoznacpizzamvc Opublikowano: