DDD, a podejście Code First - jeden model czy osobne?

DDD, a podejście Code First - jeden model czy osobne?
G1
  • Rejestracja:ponad 8 lat
  • Ostatnio:ponad 4 lata
0

Mam pewien model domenowy. Czy mogę go użyć w podejściu code first, czy lepiej pozostawić "czysty" bez żadnych zależności bazodanowych i zrobić do tego drugi?
Rozważany uproszczony model:

Kopiuj
public class Schedule
    {
        public int Id { get; protected set; }
        public string Name { get; protected set; }
        public DateTime Date { get; protected set; }
        private ISet<ScheduleEvent> _events = new HashSet<ScheduleEvent>();
        public IEnumerable<ScheduleEvent> Events 
        { 
            get => _events;
            protected set => _events = new HashSet<ScheduleEvent>(value); 
        }

        protected Schedule() { }

        public Schedule(string name)
        {
            Name = name;
            Date = DateTime.UtcNow;
        }

        public void Update()
        {
            Date = DateTime.UtcNow;
        }
    }

Jak to ugryźć, lepiej zrobić drugi ScheduleEntity czy działać na samym Schedule?

somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:około 3 godziny
  • Lokalizacja:Wrocław
0

Cały model to jedna klasa? To chyba nie ma sensu bawić się w DDD. Nie wiem też, czy jest sens używać ORMa do tego. W ogóle nie wiem czy jest sens.

W ogólnym przypadku, to jeśli Twój model miałby mieć jakieś zależności od ORMa, to to nie będzie już model domeny, a więc trudno mówić o DDD. EF chyba wciąż nakłada na programistę szereg wymagań odnośnie tworzenia klas mapowanych na bazę, więc stosując ten ORM nie da się osiągnąć persistence ignorance. Oddzielny model składowania może być rozwiązaniem tego problemu. Alternatywy to zmiana ORMa na inny albo olanie DDD.

edytowany 1x, ostatnio: somekind
Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:UK
  • Postów:2235
0

Wszystko zalezy od tego czy w Twoim konkretnym przypadku uzywanie tej samej klasy wymagalo by wprowadzenia jakichs zaleznosc miedzy domena a warstwa perzystencji. Jesli takich zaleznosci nie ma, i uzywana implementacja perzystencji (w tym przypadku EF) nie wplywa na "wyglad" modelu to nie ma potrzeby wprowadzac dodatkowego modelu do mapowania z baza.

somekind napisał(a):

EF chyba wciąż nakłada na programistę szereg wymagań odnośnie tworzenia klas mapowanych na bazę, więc stosując ten ORM nie da się osiągnąć persistence ignorance. (...) Alternatywy to zmiana ORMa na inny albo olanie DDD.

Bzdura, szczegolnie jesli mowa o EF Core. To juz NHibernate naklada wiecej wymagan. W EF Core 2.1 w zasadzie ciezko znalezc jakies "wymagania" co do tego jak ma wygladac POCO. No chyba tylko w przypadku wprowadzania many-to-many.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Zobacz pozostałe 2 komentarze
somekind
EF Core też przecież wymuszavirtual.
Aventus
Tylko przy lazy loading, zresztą da się i bez tego ale to jeszcze gorsze rozwiązanie. Inna sprawa że w DDD nie powinno się raczej używać lazy loading, model powinien mieć wszystko co potrzeba podczas ładowania z bazy. A jeśli ma referencje do czegoś czego rzadko potrzebuje to mamy raczej problem z tym jak zaprojektowalismy model. Poza tym ja ogólnie uważam że Lazy Loading jest często nadużywane i świadczy o złym zaprojektowaniu. Nie ważne czy mówimy w kontekście DDD czy nie.
somekind
Tylko przy lazy loading - no i w NH też tak jest. Więc jeśli ot ma byc jakiś argument przeciwko, to uderza w oba ORMy. Co do samego mechanizmu, to kiedyś myślałem, że to fajne, teraz zupełnie tego nie potrzebuję. Ale twórcy ORMów zdaje się ciągle uważają to za istotny ficzer.
Aventus
Chodzilo mi o uzywanie wirtuali w navigation property, o ile mnie pamiec nie myli to w NH nadal jest to wymagane. No ale mniejsza z tym. Co do lazy loading to ze mna bylo tak samo, w pelni sie zgadzam.
somekind
No właśnie w NH to nie jest i nie było wymagane. Jeśli nie chcesz używać lazy ani interceptorów, to nic nie musi być virtual.
._.
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 6 lat
  • Postów:250
0

stosując ten ORM nie da się osiągnąć persistence ignorance. Oddzielny model składowania może być rozwiązaniem tego problemu. Alternatywy to zmiana ORMa na inny albo olanie DDD.

Odnośnie do tej alternatywy to zabrzmiało jak byś namawiał do tego aby niestosować oddzielnego modelu dla Persistence z Domain Modelem. Czy ja dobrze rozumiem.?

Wszystko zalezy od tego czy w Twoim konkretnym przypadku uzywanie tej samej klasy wymagalo by wprowadzenia jakichs zaleznosc miedzy domena a warstwa perzystencji. Jesli takich zaleznosci nie ma, i uzywana implementacja perzystencji (w tym przypadku EF) nie wplywa na "wyglad" modelu to nie ma potrzeby wprowadzac dodatkowego modelu do mapowania z baza.

Tak, ale nie ma co czarować, wtedy to nie jest żaden model domeny tylko model bazodanowy a dokładniej jest to struktura dla mapowania obiektowo relacyjnego.

Bzdura, szczegolnie jesli mowa o EF Core. To juz NHibernate naklada wiecej wymagan. W EF Core 2.1 w zasadzie ciezko znalezc jakies "wymagania" co do tego jak ma wygladac POCO. No chyba tylko w przypadku wprowadzania many-to-many.

No właśnie o te niepotrzebne Identyfikatory, się rozchodzi.

@Greg1 Ten Code First to nie jest tak jak to przedstawia MS. Oni robią z tego coś na wzór metodologi pracy, co jest mniej więcej żałosne. Ponieważ auto mapowanie ORM'a to nie jest nic nowego. A samo EF pierwotnie miało się skupiać na "DB First", może stąd wziął się problem, o którym wspomniał @somekind, nie wiem...

edytowany 2x, ostatnio: ._.
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:około 3 godziny
  • Lokalizacja:Wrocław
2
._. napisał(a):

Odnośnie do tej alternatywy to zabrzmiało jak byś namawiał do nie stosował oddzielnego modelu dla Persistence z Domain Modelem. Czy ja dobrze rozumiem.?

Ja tylko przedstawiam alternatywy. Sam osobiście zawsze skłaniam się do niestosowania DDD na siłę.

Aventus
Dokładnie, DDD powinno się stosować tam gdzie przyniesie korzyści. DDD nakłada również szereg ograniczeń więc nie powinno się go używać "bo tak".
._.
Jakie ograniczenia ?
._.
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 6 lat
  • Postów:250
2

@Aventus
DDD niczego nie narzuca, to ludzie sami sobie coś narzucają. DDD to zbiór propozycji projektowych, które nie są nowością, DDD raczej skupia się na ich sensownym zastosowaniu a to nie jest proste. Persistence ignorance to pomysł Fowlera w DDD jest to raczej efekt uboczny stooswania Domain Modelu. W zależności od tego jaką książkę weźmiesz, możesz znaleźć propozycje czerpiące z Port Adapter, SOA, ale i też bez. Ludzie rozpoznają DDD na podstawie tego, że jest tam jakieś repzytorium, domain model i 4 warstwy (W ogóle pomijając coś takiego jak "Mapa Kontekstu" czy "Rdzeń Oddzielony".). Agregat możesz równie dobrze tworzyć bez repository i ustawiać go streamem. Jak masz np. Produkt z ładnymi metodami biznesowymi, który ma kategorie to poco robić wszystko na jedno kopytko. Niech model domeny używa tylko identity filed od kategorii a samą kategorię możesz ustawiać serwisem bazodanowym poza domeną. Nie przepadam za gadaniem typu "DDD alternatywa dla CRUD'a" i na odwrót. Może tylko ja tak mam, ale odbieram to tak, jak by KTOŚ chciał robić wszystko na jedno kopytko. Zamiast trzymać najważniejsze narzędzia za pazuchą i być gotowym do użycia ich w odpowiednim momencie.

edytowany 1x, ostatnio: ._.
Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:UK
  • Postów:2235
1

Ja nie wiem co Ty tam odbierasz, nie przypisuj mi rzeczy których nigdy nie wypowiedziałem bo to paranoja jakas. Aż mi się nie chce z taką osobą w konstruktywna dyskusje wdawać bo o konstruktywnosci nie ma w takim przypadku mowy.

Aha, i DDD narzuca pewne ograniczenia tak jak wszelkie inne podejścia architektoniczne, standardy i wzorce. Ot choćby w DDD takie agregaty- jak nie masz agregatów, rich entities etc. to nie ma mowy o DDD. Więc ograniczenia, czy raczej pewne narzucone kwestie istnieją. Twierdzenie że tak nie jest to fanatyzm.

To że Cie ludzie plusuja tylko potwierdza jak ograniczeni niektórzy potrafią być i jakie mają problemy z czytaniem ze zrozumieniem- człowiek napisze słowo a reszta doda sobie 10 zdań i ocenia na podstawie tego jak daną wypowiedź "odbiera".


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Zobacz pozostałe 3 komentarze
._.
POZA TYM MASZ RACJĘ AGREGACJA TO TOTALNA NOWOŚĆ W OOP.
vpiotr
CAPS LOCK OFF
Aventus
"POZA TYM MASZ RACJĘ AGREGACJA TO TOTALNA NOWOŚĆ W OOP" - o czym Ty w ogóle do mnie mówisz? Ty naprawdę sobie uroiłeś sobie jakieś dziwne tezy których ja nigdy nie stwierdziłem. Ps: pisanie w caps locku to błazenada. Teraz naprawdę kończę dyskusje zanim się jeszcze bardziej rozkrecisz.
._.
Ot choćby w DDD takie agregaty- jak nie masz agregatów Agregat, Encja to nie jest wymysł Evansa. To są podstawy OOP. Wytykanie czegoś takiego jak wciśnięty CapsLock jest gorzej niż żałosne.
vpiotr
@ ._.: tylko jeśli zwracamy uwagę komuś po siedemdziesiątce. Hasło do wyguglania: netykieta.
._.
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 6 lat
  • Postów:250
0

Już rozumiem, z czego wynikają twoje ograniczenia w stosowaniu DDD. Prowadzeniu dyskusji również.

._.
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 6 lat
  • Postów:250
0

Nigdzie nie napisałem, że to o czym mówię to obraz tego, jak ty myślisz, czy programujesz. Ja po prostu chciałem wtrącić swoje przemyślenia nawiązując do twojej rozmowy z @somekind. Dokleiłem cię na zaczepkę, bo mi nie odpowiedziałeś na pytanie i spodziewałem się rozmowy w przyjaznym tonie. Wiesz może ci się nie podobać to co piszę, czy tam mój awatar, nie wiem, ale obrażanie innych dlatego, że mnie plusują, to już naprawdę jest słabe.

edytowany 2x, ostatnio: ._.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.