Tak czytałem o tym, ale chyba w moim przypadku nie będzie to raczej prosta aplikację CRUDową. CRUDowe aplikacje kojarzą mi się z szablonem, okno główne z DataGridView gdzie jest zbiór jakiś obiektów np. zlecenia, pracownicy, wyroby itp. i dodatkowo otwieranym/wydzielonym oknem do tworzenia edycji pojedynczych obiektów. i takie pary na zbiór i add/edit tworzone są dla każdego rodzaju encji.
Z grubsza masz rację. :)
Ja mam plan pracować na takich parach zbiorów CRUD ale i na czymś co w DDD chyba nazywa się agregatem jakiejś encji. Czyli jeżeli taka kalkulacja wyrobu produkcyjnego składa się z listy materiałowej i marszruty technologicznej oraz z listy osób: autor , sprawdzający, zatwierdzający (z datami) oraz z listą na wszystkie poprzednie kalkulacje do tego wyrobu, to ja nie chce zagnieżdzać się w coraz głębsze pary lista/wykaz oraz add/edit encji, tylko działać bezpośrednio na agregacie który odwzorowywałby wpływ na te encje z którymi jest powiązany (sporo system musiałby pilnować, np. edytując w agregacie kalkulacji jakieś czynności elementarne, system miałby sam podbijać wyżej wersje danej czynności elementarnej ale i operacji technologicznej w której jest ta czynność, marsztury w której jest ta oparacja i finalnie kalkulacji w której jest ta marszruta - szaleństwo ;) ale tak to działa dobrze w excelu i chce to przenieść do systemu)
No to faktycznie jest coś, w czym podejście DDD ma sens.
Interesuje mnie bardziej taka praca aby w przypadku jeżeli jeden człowiek edytuje jakiś agregat i coś zmienia to aby ten agregat był zablokowany do edycji przez innych oraz aby Ci inni chcąc również edytować ten zablokowany agregat mieli informację kto go teraz edytuje/blokuje.
I to jest właśnie pessimistic concurrency.
Poza tym nie czuję za bardzo przypadku gdy dwie osoby tworzą jakiś nowy agregat/encję a system ma automatycznie inkrementować sygnaturę, oznaczenie lub coś innego dla tego nowego agregatu.
Odpowiedź jest w pytaniu - automatycznie. :)
Jeśli tworzysz ten nowy agregat przez repozytorium, to raczej nie ma problemu w tym, żeby taką sygnaturę pilnować i automatycznie ją numerować. Generowanie numerów warto wtedy wydelegować do oddzielnej strategii, aby móc łatwo zmieniać zasady numeracji.
Jakoś nie ogarniam przypadku aby dwie osoby przypadkiem nie zdefiniowały dwa razy tego samego, jak system miałby to uniemożliwiać. Chodzi o przypadek UnitOfWork, gnie coś tworzę narobię się przy tym sporo czasu (złożyć taką kalkulację to nawet pare godzin) ale dopóki to tworzę to system nie zapisuje tego w bazie, dopiero po zakończeniu pracy aktualizuje to wszystko i dopiero mi się zapisuje w bazie danych.
Rozwiązania tego problemu nie znajdziesz w żadnej książce.
Skoro obiekt jest długotrwały w edycji, to i tak na początku należałoby zablokować jakiś numer dla niego (np. tworząc nowy rekord w tabeli przechowującej wykorzystane numery). Ale i tak najważniejsza jest odpowiedź na pytanie - co to znaczy "zdefiniować dwa razy to samo"? Jak program ma rozpoznać, że dwie osoby robią to samo, według jakich kryteriów?
poza tym w niej jeszcze facet chyba pisze ręcznie ORM'a, bo stąd chyba te wszystkie klasy typu:
Z tego co widzę, to tam się dzieje jakieś magiczne cachowanie repozytoriów. Nie mam pojęcia po co, ale to generalnie nie wygląda na dobry pomysł. Generalnie repozytoria mają ukrywać ORMa, który sam powinien zajmować się cachowaniem niektórych encji. Tylko EF chyba tego nie obsługuje sam z siebie.