Nie wiem, ja tam używam EF Core z wartościami przekazywanymi przez konstruktor i prywatnymi properties. Mało tego, możesz nawet używać read only properties.
To wspaniale, że Microsoftowi za trzecim chyba razem udało zrobić się ORMa, który ma ficzery obecne w ORMach od kilkunastu lat.
Tylko pytanie było o EF, Ty odpowiadasz o EFC. Tak trochę nie na temat, bez związku i w ogóle w stylu "a u was biją murzynów".
Nie chcę nic mówić ale na dzień dzisiejszy to NHibernate bardziej łamie PI... I tak naprawdę nie ma nic złego w takim drobnym łamaniu PI (np. wymagany virtual w NH. Chociaż to brzydko wygląda).
No tyle, że jak łamiemy PI, to już go nie mamy, więc po co udawać, że jest?
A virtual
w NH nigdy nie był, ani nie jest ogólnie wymagany.
Liczba rzeczy jakie musisz zmieniać w POCO aby było kompatybilne z EF Core: 0. Naprawdę. Wszystko można skonfigurować przez konwencję EF.
No świetnie, tylko jak pokazał niedawny temat, nadal nie można nawet wybrać rodzica z odfiltrowaną kolekcją dzieci.
Swoją drogą muszę kiedyś sprawdzić, jak łatwo zmapować Dictionary.
Biorąc pod uwagę że repozytoria oficjalnie narodziły się w książce Fowlera wydanej w 2002 roku, natomiast DDD oficjalnie narodziło się w książce Evans wydanej w 2003 roku
Uch... to będzie brutalne, ale ktoś Ci to musi napisać.
Wzorce projektowe nie biorą się z książek, są efektem praktycznych zastosowań, które się sprawdziły i zdobyły popularność. Niektórzy ludzie je potem opisują, tak jak to zrobił GoF z podstawowym zestawem wzorców, czy tak jak zrobił Fowler z wzorcami "enterprise".
Technicznie rzecz biorąc, repozytoria czyli pseudo-kolekcje modeli domenowych stanowiące abstrakcję nad źródłem danych istniałyby nawet gdyby nikt ich nigdy nie opisał ani nie nazwał. I nadal tak samo różniłyby się od innych obiektów/wzorców.
Repozytoria to nie są wrapery na ORMa, repozytoria nie służą do crudowych operacji na tabelach bazy za pośrednictwem anemicznych encji. Jeśli ktoś ma takie obiekty, to to nie są repozytoria - nawet jeśli je tak nazwie. Nazewnictwo niezgodna z zachowaniem i implementacją nie jest dowodem sprytu tylko ignorancji bądź niechlujstwa.
1 Skąd wziąłeś stwierdzenie o DAO? Wszystkie encje to POCO's i są w całości zdecouple-owane od implementacji ORM'a, nawet virtuali na kolekcjach dla lazy loadu nie znajdziesz (co zresztą jest imho anty-praktyką)
Mam wrażenie, że nie do końca rozumiesz co to DAO, skoro piszesz coś o encjach POCO. DAO to takie obiekty dające dostęp do warstwy perzystencji, najczęściej nieprawidłowo nazywane repozytoriami.
2,3 Już było podnoszone i jest to opinia
To nie jest opinia. Wpychanie logiki biznesowej do kontrolerów sprawia, że:
- nie masz już MVC;
- aplikacja jest nietestowalna bez postawienia serwera HTTP albo mockowania kontekstu HTTP. Słabe to strasznie.
4 Każdy agregat ma oddzielne repozytorium, aż musiałem się upewnić czy nie mam jakiegoś dzikiego repozytorium dla encji która nie jest Entity Rootem które kiedyś dodałem ale przyznam że na pierwszy rzut oka nie widzę.
Możliwe, że moje wrażenie jest po prostu mylne, po prostu zobaczyłem bardzo zbliżoną liczbę repozytoriów i encji, co by świadczyło raczej o ich nieprawidłowym użyciu. Jeśli nie to jest powodem, to strzelam, że przykład, który wybrałeś sobie na swoją aplikację jest zbyt trywialny, aby stosować tu DDD.
8 Jak chcesz to inaczej zrobić i co w alternatywnej implementacji będzie lepsze? Jakoś trzeba na bazie zapisać która ikona wyświetla się na widgecie.
Baza powinna trzymać to, co jest istotne w modelu biznesowym. To warstwa prezentacji powinna tenże model na elementy ekranowe konwertować. Nie wiem do czego konkretnie ma to służyć, więc nie mogę odpowiedzieć bardziej precyzyjnie.
9 To nie infrastruktruralny kod, User jest zcouple'owany do innych encji domenowych takich jak UserWidgets, w przypadku wydzielenia tego do
infrastruktury nie jesteś w stanie odwołać się do nich z powrotem w domenie z powodu circular ref, jeśli uważasz to za anty praktykę, to proszę o podanie alternatywy.
Zarządzanie rolami i użytkownikami, to jest infrastruktura. Po co w ogóle odwoływać się do tych obiektów w domenie?
11 O jakiej klasie infrastrukturalnej mówisz, przecież to czysty serwis z jedną metodą.
O Tuple<,>
. Tam powinna być jakaś konkretna klasa.
Ta aplikacja to ok 8 tys linii kodu + markup i piszę ją sam po godzinach 4fun od 2 lat. Doszukiwanie się stringów w walidacjach, czy logiki która nie została jeszcze wyekstraktowana do serwisów (bo zwyczajnie nie było sensu pisać serwisu dla 2 linijek kodu!) tylko dlatego żeby na siłę pokazać "temu siakiemu owakiemu który śmie napisać że niby dobre praktyki!!oneone1 ja mu pokaże!!" jest nadużyciem. Jeśli coś znajdujesz, to wymień i ja to poprawię jeśli ma sens w wolnej chwili (tak jak przyznałem Ci rację w kilku punktach powyzej), nie sądzę że znajdziesz kod jakiegokolwiek programisty który byłby idealny (lub pasujący do swoich przekonań), zawsze do czegoś idzie się doczepić.. dlatego, naprawdę.. teksty typu "Ten kod to zbiór najpopularniejszych antywzorców, kultów cargo, niekiedy doprawione zwykłym spaghetti" są toksyczne i nic do dyskusji nie wnoszą.
Fajnie, że włożyłeś dużo pracy, i że chcesz się podzielić, ale uważam po prostu, że aby reklamować to jako zbiór dobrych praktyk powinieneś to najpierw bardziej oczyścić i zrefaktoryzować. Na razie to wygląda jak taki zbiór "wprawek" - tu sobie przetestuję coś, tam coś innego, żeby sprawdzić jakieś podejście, które w pracy się przyda. Też mam takie projekty, tylko się nimi nie chwalę.
No i może jednak dziedzina jest zbyt prosta, żeby robić z tego DDD, skoro masz tak mało logiki biznesowej, a tak wiele cruda.