Czy obiekty ignorujące trwałość są w stanie zaimplementować opóźnione ładowanie?

Trwałość Ignorancja jest zastosowaniem zasady pojedynczej odpowiedzialności, co w praktyce oznacza, że ​​Obiekty Domeny ( DO ) nie powinny zawierać kodu związanego z trwałością, a jedynie logikę domeny.

a) Zakładam, że oznacza to, że kod, który kontaktuje się z niższymi warstwami (tj. warstwami trwałości), żyje poza modelem domeny w innych klasach ( OC ) warstwy logiki biznesowej?

b) Jeśli moje założenie pod a) jest poprawna, to ZROBIĆ , powiedzmy Customer, nie zawiera metody takie jak GetCustomersczy GetCustomerByID?

c) Jeżeli moi założenia pod wa) i b) są prawidłowe, i przy założeniu, że Customerobiekt domeny używa lazy ładunkowe niektóre jego właściwości, a w pewnym momencie Customerwewnętrznemu logiczna musi skontaktować OC , co z kolei pobiera odroczonego danych. Ale jeśli Customertrzeba skontaktować się z OC w celu otrzymania odroczonych danych, to nie możemy tak naprawdę twierdzić, że Obiekty Domeny nie zawierają logiki związanej z trwałością ?!

Dziękuję Ci

ODPOWIEDZI NA Jkohlhepp

1) Zakładam, OrderProvidera CustomerProviderzajęcia są zawarte w warstwie logiki biznesowej?

2) Z Twojej odpowiedzi wynika, że ​​moje założenia w punkcie b) są prawidłowe?

3)

... sprawdziłbym, czy jakieś prywatne pole zamówień jest zapełnione, czy jest puste. Jeśli jest zerowy ...

Ale o ile mogę stwierdzić, gdy tylko kod domeny musi sprawdzić, czy orderpole prywatne zostało zapełnione, a jeśli nie, kontaktując się z OrderProvider, już naruszamy zasadę PI ?!

Wierzę, że masz rację w swoich założeniach A i B dotyczących uporczywej ignorancji.

To, jak najlepiej osiągnąć leniwe ładowanie obiektów bazy danych, zależy w dużej mierze od konkretnego problemu i implementacji. Spróbuję jednak uzyskać ogólną odpowiedź na to, jak zrobić leniwe ładowanie, jednocześnie zachowując rozdzielenie obaw między trwałością a klasami logiki domeny.

Zwykle wdrażam ignorancję uporczywości, używając następujących klas:

• Klasy domen - np. Klient
• Klasy dostawcy / repozytorium - np. CustomerProvider
• Ogólne klasy zapytań do baz danych - np. DatabaseQuery

Klasa DatabaseQuery byłaby odpowiedzialna za użycie sterownika bazy danych do zapytania do bazy danych i złożenia wynikowych danych w ogólny zestaw wyników, taki jak DataTable. CustomerProvider byłby odpowiedzialny za użycie klasy DatabaseQuery do wykonania SQL na bazie danych i wykorzystanie wyników tego SQL do złożenia instancji klienta. Klient byłby „czystym” obiektem domeny zawierającym dane i logikę związaną z klientami.

Jeśli chodzi o to, czy klasy dostawców powinny znajdować się w warstwie biznesowej, czy w warstwie danych, nie mam zdecydowanej opinii. Widzę sprawę dla obu. Ważną częścią jest rozdzielenie obowiązków między klasy.

Omówmy teraz leniwe ładowanie. Powiedzmy, że chciałem, aby Klient miał zbiór Zamówień, ale nie chcę wyciągać Zamówień z bazy danych, chyba że konsument spróbuje uzyskać do nich dostęp. Na zlecenie klienta utworzę właściwość o nazwie Zamówienia. W module pobierającym tę właściwość sprawdziłbym, czy jakieś prywatne pole zamówień jest wypełnione, czy też jest puste. Jeśli ma wartość NULL, załaduj zamówienia z bazy danych za pomocą usługi OrderProvider. W przeciwnym razie po prostu zwróć kolekcję, która została już załadowana.

Moim zdaniem potrzeba skontaktowania się z Klientem OrderProvider nie narusza PI. Klient wciąż nie wie, jak otrzymuje zamówienia. Po prostu wie, że dostaje je od OrderProvider. Mogą istnieć inne powody, aby oddzielić klienta od OrderProvider, ale nie sądzę, że PI jest tutaj problemem.

Zakłada się, że ignorujesz wytrwałość ręcznie. Jeśli używasz frameworka ORM, takiego jak Entity Framework lub Hibernacja, to te frameworki mają na ogół funkcje do automatycznego opóźnionego ładowania.

Masz tylko pewną klasę połączeń, która wypełnia obiekty domeny (powiedzmy coś zwanego „repozytorium”). Możesz wdrożyć leniwe ładowanie lub dowolny inny schemat spójności pamięci podręcznej, a obiekty domeny nie są mądrzejsze. Oddzielasz odpowiedzialność za wypełnianie obiektów domeny od bycia obiektami domeny.