Czy twoje pierwsze lekcje kodu są twoimi klasami domeny?

Question

Nie jestem pewien, czy potrafię to poprawnie wyrazić, ale ...

Zaczynam tworzyć rozwiązanie przy użyciu kodu Entity Framework i zaczynam odczuwać, że zanieczyszczam swoje klasy domen (klasy EF użyje do wygenerowania bazy danych) ze zbyt dużą ilością informacji specyficznych dla DB: Muszę uczynić pewne metody wirtualnymi, aby mogły wystąpić leniwy ładunek, dodam atrybuty wyraźnie ukierunkowane na konfigurację DB do moich właściwości, i tak dalej . Martwi mnie również to, jak wszechobecne będą te zajęcia w całym projekcie.

Po pierwsze, czy mam sens i/lub czy zasadniczo nie rozumiem, w jaki sposób należy zastosować EF?

Po drugie, jeśli rozumiem to prawo, moje pytanie brzmi: czy ktokolwiek inny rozróżnia ich pierwsze klasy kodu używane do generowania ich DB i ich klas domeny (być może przy użyciu automatycznego mapowania do wypełnienia jednego z nich inny)?

Answer 1

Spędziłem dużo czasu próbując różnych podejść do tego problemu. W swojej prostocie jest to możliwe i bardzo łatwe dzięki Entity Framework, aby korzystać z klas danych również jako klasy domenowe.

Z mojego doświadczenia wynika, że ​​w małych projektach można uniknąć używania klas EF jako klas domeny. Jest to szybkie i proste, jednak wraz z rosnącymi projektami zaczynają się pojawiać i pojawiają się problemy, ponieważ nie można w żaden sposób kontrolować dostępu.

Najczęstszym scenariuszem jest ekspozycja właściwości nawigacji na klasach EF. Twoja cała aplikacja będzie teraz mogła nawigować po całym zestawie danych. Tak więc w tym modelu rezygnujesz z kontroli nad swoimi danymi i obiektami domeny.

Istnieje kilka zalet posiadania oddzielnych klas domeny od EF. Przede wszystkim nie będziecie tak mocno związani z EF lub kod-pierwszy. Dzięki poziomowi separacji/niezależności będziesz mógł zmienić strukturę danych, jeśli sobie tego życzysz. Po drugie, możesz efektywniej kontrolować swoje dane.

Osobiście osiągnąłem pragmatyczny punkt, w którym podejmuję tę decyzję na początku każdego projektu. Jeśli projekt jest mały i zawarty, wówczas mogę uniknąć tej dodatkowej abstrakcji na rzecz prostoty. W prawie zawsze średnim i/lub dużym projekcie mam separację.

Answer 2

Jeśli zamierzasz używać zasad SOLID w swoim kodowaniu, naprawdę powinieneś oddzielić implementację danych (w twoim przypadku kod EF pierwszy) od logiki domeny/biznesu. Mapowanie ich jest nieco obciążające, ale zastanów się, co się dzieje, gdy potrzebujesz dostępu do niektórych danych z usług internetowych?

Ponadto, swoje zajęcia domen często zawierają obliczana lub uzyskane wartości (np Imię i nazwisko, adres), który nie będzie obecny w waszych klasach baz danych i potencjalnie odwrotnie (np bazie zalogowaniu info)

ja w pierwszej kolejności przeszukaj wzorzec repozytorium.