Wiele lub pojedyncze repozytoria z LINQ

Question

Czytałem Rozdział 11 (Testable Design Patterns) w profesjonalnej książce ASP.NET MVC 1.0. W przykładach w tym rozdziale dostęp do danych jest podzielony na wiele repozytoriów: IOrderRepository, IP Productctepository itd. To wszystko ma sens: pojedyncze repozytorium dla pojedynczej klasy danych.

To jednak trochę załamuje się, gdy weźmiesz pod uwagę powiązania między tabelami: Zamówienie zawiera pewną liczbę Produktów. Gdy klasa Zamówienia jest tworzona przez LINQ-SQL, klasa zamówienia będzie miała kolekcję Produktów, która wylicza wszystkie produkty związane z tym zamówieniem. Korzystając z tej kolekcji, omijamy ProductRepository.

Dlatego, podczas szyderstwa, będę musiał nie tylko sfałszować OrderRepository i ProductRepository, ale także będę musiał wypełnić kolekcję Produktów w zwróconych obiektach Zamówienia. Co oznacza, że ​​wyśmiewany OrderRepository musi wiedzieć o wyśmianym ProductRepository i tak dalej.

Wydaje się, że marnowanie tych kolekcji, które LINQ tak dla mnie stworzono, wydaje się marnotrawstwem, więc moje pytanie brzmi, czy w tym przypadku pojedyncze repozytorium nie miałoby większego sensu?

Answer 1

Inne czynniki, które należy rozważyć prawdopodobny żywotność produktu i prawdopodobieństwo konieczności zmiany z LINQ-SQL do innego O/R odwzorowującym w dowolnym momencie w życiu. Im mniejszy projekt, tym mniej krytyczny produkt, tym mniej musisz się martwić o abstrakty minutace do n-tego stopnia.

Answer 2

Twój opis problemu to typowy podręcznikowy przykład tego, że zbyt wiele informacji na temat "to jest dobre, to jest złe" staje się powodem, dla którego programista tworzy oprogramowanie w taki sposób, w jaki został stworzony, zamiast przyglądać się problemowi i tworzyć oprogramowanie naprawić ten problem.

Przykład: opis problemu nie jest problemem do rozwiązania: masz aplikację do utworzenia dla swojego klienta, to jest problem, który powinieneś rozwiązać. Jeśli twój wybór narzędzi utrudni ci życie, wyrzuć je i używaj tego, co działa: skoro szyderstwo nie działa, po co zawracać sobie głowę? Och, bo ktoś powiedział, że twoje oprogramowanie będzie ssać, jeśli nie będziesz kpił? Czemu?

Podejmowałeś niektóre elementy DDD tu i tam, ale przegapiłeś kilka ważnych elementów: Produkt jest zbiorczym katalogiem głównym. Oznacza to, że powinieneś otrzymać produkty z własnego repozytorium. Tak, to łagodzi funkcję nawigacji w modelu, ale to DDD dla ciebie, JEŚLI tworzysz repozytoria dokładnie tak, jak dyktuje druga część książki Evansa. Ale ... czy powinieneś?

Jeśli nie możesz odpowiedzieć na pytanie, dlaczego produkt ma własne repozytorium, ale możesz nawigować do produktów z zamówienia, nie powinieneś tworzyć repozytoriów dla zagregowanych katalogów głównych. DLACZEGO jest tam to repozytorium? Jeśli jest tam, czy nie powinien to być TYLKO punkt, w którym można uzyskać Produkty? (więc nie przez leniwy załadunek!).

To rzeczywiście spowoduje wiele kosztów ogólnych i kodu, który prawdopodobnie nie będzie potrzebny (tak ironicznie, YAGNI z pełnym skutkiem).

OK, wystarczająco dużo rantowania. DDD to około myślenie. Tak więc domena powinna kierować projektem, a praktykując ją otrzymasz model domeny, który reprezentuje rzeczywistość. To nie znaczy, że powinieneś zaimplementować dużo kodu tylko dlatego, że czytasz gdzieś powinieneś. Zamiast tego, jeśli rozpoznajesz elementy domeny, zagregowane korzenie itd., Musisz gdzieś umieścić zachowanie dla tych typów, np. wewnątrz klas domeny. Możesz umieścić logikę pobierania w oddzielnych klasach, takich jak logika pobierania zorientowana na zamówienie w repozytorium zamówień, ale nie będzie to repozytorium w ścisłym tego słowa znaczeniu (np. Nie ma własnej lokalnej pamięci podręcznej itp.). To nie jest takie złe, chodzi tylko o to, co powinieneś stworzyć dla swojego klienta.

Po pierwsze: pomyśl, po drugie: pomyśl, a po trzecie: pomyśl ... jeszcze raz. Co wydaje ci się logiczne. Zrób listę zalet/wad opcji, które posiadasz i wybierz ten, który wydaje ci się najbardziej odpowiedni. Dokumentuj ten wybór i dlaczego wybrałeś tę, a nie alternatywę.To daje więcej korzyści dla opiekunów niż jakiekolwiek inne źródło: dokumentujesz alternatywy i dlaczego ich nie wybrałeś, robisz badania, co będzie dla ciebie skuteczne, i wybrałeś jedną.

Inżynieria oprogramowania nie jest trudne, tylko że w dzisiejszych czasach wydaje się moda po prostu zrobić pierwszy i myślę później, bez właściwego uzasadnienia dlaczego można by zrobić to w ten sposób, a nie inny sposób.

Powodzenia :)