Schemat repozytorium i wiele powiązanych obiektów podstawowych lub obiektów biznesowych - jedno lub więcej repozytorium?

Question

Rozważam wdrożenie wzorca repozytorium (ponieważ to, co wymyśliłem, było w 90% jego implementacją) i natrafiłem na pytanie projektowe - gdzie mam dwa lub więcej podstawowych obiektów biznesowych (na przykład Business i Kontakt w aplikacji CRM), BO może być silnie powiązane lub w ogóle niezwiązane.

W tej sytuacji, należy realizować jedną repozytorium (CrmRepository na przykład z .addBusiness .addContact()(), i inne), lub wielu repozytorium (BusinessRepository, ContactRepository każdy z własnym .add() .delete() i wsp.).

Jaka jest najlepsza praktyka w tej sytuacji?

Podstawowy DAL to EF4.

Pozdrowienia

Moo

Answer 1

Robiliśmy dużo myślenia niedawno w mojej pracy i natknąłem się na kilka artykułów, które pomogły nam wizualizować i projektować nasze repozytoria w spójny sposób.

Z tego, co odkryliśmy, jedną z lepszych praktyk jest utworzenie jednego repozytorium na agregat root. Zagregowany katalog główny będzie typem jednostki, w której należy odwoływać się do tego typu jednostki, aby dotrzeć do typów wartości podrzędnych. Z bazy danych można było wyszukiwać tylko typ jednostki, a dowolne dziecko Typy wartości musiałyby być wykonywane z Entity.

Z twoimi informacjami w twoim pytaniu wydaje się, że Biznes byłby zbiorczym rootem, a tym samym typem jednostki i wymagałby własnego repozytorium. Ponieważ Kontakt może żyć niezależnie, co może być również głównym źródłem danych. Oba obiekty mogą mieć odniesienia do siebie nawzajem i używać repozytorium w celu załadowania firm z kontaktu lub załadowania kontaktów z firmy za pośrednictwem odpowiedniego repozytorium.

Ostatnio dużo czytam, więc mam nadzieję, że mam jakiś sens w moim procesie myślowym.

Niektóre linki

Aggregate Root

Entities, Value Objects, Aggregates and Roots

Answer 2

I całkowicie zgadzam się z Markiem na ten temat, ale dodać trochę więcej. Kiedy patrzysz na korzyści wynikające z tworzenia Generic Repository, popularnym tupotem jest IRepository i Repository. Jedna rzecz, którą odkryłem, jest o wiele bardziej użyteczna, ujawniona przez Jeremy'ego D. Millera (nie można znaleźć odniesienia) na temat generycznych metod na poziomie metody.

Więc moja IReposity będą miały podobne metody to:

T FindByKey<T>(int key); 
IEnumerable<T> FindAll(); 
T FindBy<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression); 
void Update<T>(entity); 

Następnie, w zależności od swojej filozofii, można przechodzić wokół Repository klasy i kwerendy go bezpośrednio, lub dokonać repozytorium streszczenie wdrażania i zmusić go używają do być zamknięty przez wyraźnego repozytorium tak:

CrmRepository : Repository 
{ 
    FindByCustomerId(int customerId) 
    { return FindByKey<Customer>(customerId);} 
}