Četl jsi místní E-shop v ASP.NET? Tam se používá tuším AutoMapper.
Nad něčem podobném jsem přemýšlel, ale nějak nevidím výhodu v tom, 1:1 překlápět Entity třídy na ViewModel. V čem je výhoda?
Podstatou ViewModelu je IMHO to, že to není plnohodnotná entita, ale co nejmenší pomocná třída. I když mi to přijde také podivné, podle Best practices se to tak dělá. Výhodou je, že ViewModel nemusí kopírovat rozhraní entity.
Na AutoMapper se vykašli. Na začátku jsem ho měl rád a usnadnil ti práci, jakmile ale pak něco zrefaktoruješ, tak už ti to přestane mapovat property a musíš to stejně setupovat sám (a dost blbě se to debuguje ...). Jakmile pak máš nějaké vnořené mapování, tak to taky není žádná sláva, osobně jsem si zvykl pro mapování z objektu -> objekt (třeba Model na DTO, Model na ViewModel ... záleží jak si to pojmenuješ) napsat metodu sám.
Výhodu poznáš jakmile nebudeš dělat základní CRUD, ale budeš mít komplexnější scénáře. Tyhle otázky by ti měla objasnit třívrstvá architektura.
Osobně dělám POCO na každé vrstvě zvlášť a snažím se si nepřenášet závislosti tam kde nemusím. Na fakt jednoduchých věcech je to asi jedno, ale jakmile děláš něco většího, tak tě to při každé další změně potrestá.
Buďto je tu poslouchej a uděláš anemický model, kde absolutně nemáš žádný doménový model (to je právě to POCO - tam je na každé vrstvě jedna přepravka, mapuje se to mezi sebou a samotná logika je v přepravkách - je to více ale imperativní programování než objektové)... nebo je neposlouchej, udělej plný doménový model, ale pak se vykašli na věci jako UOW a repository, protože něco takového nemůže dohromady fungovat...
Mluvím o tom částečně i zde:
https://www.youtube.com/watch?…
Nesnažte se bože za každou cenu skloubit dva absolutně opačné přístupy, stejně vam z toho vyjde jen kočkopes.
Samotný EF není ani pro plný OOP přístup a rich domain model stavěný...více zde:
https://blog.inf.ed.ac.uk/…olid-design/
https://vaughnvernon.co/?…
A HLAVNE!!!!:
https://lostechies.com/…k-scorecard/
pardon oprava textu (toto forum z nejakeho nadpozemskeho duvodu nedovoluje editovat, takže mi nezbývá než spamovat). "Samotná logika je v servisách" u anemického modelu.
Marian Benčat Jan Vargovský díky za odpovědi. Asi se mám co učit. Jde o to, že tu máme větší projekt, který se rozšiřoval bez nějaké "architektury" a momentálně to dost hoří a celé se to sype -> bude se to přepisovat. Proto máme volné ruce a možnost to celé nastavit nějak rozumně. Chceme to udržet tak jednoduché jak jen to půjde, ale nějak rozumně navrhnuté.
Jedná se o WPF aplikaci, potřeba jsou typické úkony a práce s daty z
databáze.
Pokud máte jště nějaké tipy co nastudovat kolem toho, budu rád. Díky.
... samotná logika je v přepravkách ...
O tom ale přece nikdo nemluvil 
když řeknu DTO jako POCO, tak tam do toho neseru přece žádnou
logiku 
od toho mám tu
vrstvu nebo další servisy.
A četl si co jsem napsal hned pod tím??
"pardon oprava textu (toto forum z nejakeho nadpozemskeho duvodu nedovoluje
editovat, takže mi nezbývá než spamovat). "Samotná logika je v servisách"
u anemického modelu."
Nečetl obviously ... Máš nějaké příklady toho anemického modelu? Nějak nevidím co je blbě na tom, že máš logiku vyseparovanou někde jinde a pro přepravu dat mezi vrstvy používáš DTO.
je to v tom jednom odkazu.. v zásadě na anemickém modelu není špatně nic,.. ale není to OOP a stím jsou spojené jeho nevýhody i výhody.
Popravde se do teto debaty nechci poustet, protoze 1) toto je strašné forum a nechci každý debilní přepis řešit pomocí 10 dalších příspěvků... 2) je to tak na 2 hodky to probrat u piva
Zobrazeno 14 zpráv z 14.