Od wielu lat zajmuję się tworzeniem aplikacji dla przedsiębiorstw przy użyciu .Net Moje aplikacje zwykle mają model domeny zawierający jednostki mapujące na tabele SQL DB. Używam wzorca repozytorium, iniekcji zależności i warstwy usług.
Niedawno rozpoczęliśmy pracę nad projektami MVC 3 i debatowaliśmy, gdzie umieścić jaką logikę. Natknąłem się na cienką architekturę kontrolera / modelu FAT i zastanawiałem się, jak będzie pasować warstwa usług
Opcja 1 - Model rozmawia z usługami
Kontroler jest cienki, wywołuje metody w modelach. Modele „wiedzą”, jak załadować się z bazy danych i rozmawiać z repozytoriami lub usługami. Np. CustomerModel ma metodę Load (id) i ładuje klienta oraz niektóre obiekty podrzędne, takie jak GetContracts ().
Opcja 2 - Kontroler rozmawia z usługami
Kontroler prosi usługi o pobranie obiektów modelu. Logika ładowania / przechowywania itp. Znajduje się w warstwie usług. Model jest czystym modelem encji z samymi danymi.
Dlaczego opcja 1 miałaby być lepszym wyborem, zwłaszcza gdy mówimy o zastosowaniach korporacyjnych, moje doświadczenie podpowiada mi, aby oddzielić obawy, utrzymywać modele ORAZ kontrolery tak cienkie, jak to tylko możliwe, i mieć wyspecjalizowane usługi obsługujące logikę biznesową (np. Interakcja z bazą danych)
Dzięki za wszystkie rady i odniesienia do dobrych zasobów.