Vianoce v ITnetwork sú tu! Dobí si teraz kredity a získaj až 80 % extra kreditov na e-learningové kurzy ZADARMO. Zisti viac.
Hľadáme nové posily do ITnetwork tímu. Pozri sa na voľné pozície a pridaj sa k najagilnejšej firme na trhu - Viac informácií.

Diskusia – MVC architektúra

Späť

Upozorňujeme, že diskusie pod našimi online kurzami sú nemoderované a primárne slúžia na získavanie spätnej väzby pre budúce vylepšenie kurzov. Pre študentov našich rekvalifikačných kurzov ponúkame možnosť priameho kontaktu s lektormi a študijným referentom pre osobné konzultácie a podporu v rámci ich štúdia. Toto je exkluzívna služba, ktorá zaisťuje kvalitnú a cielenú pomoc v prípade akýchkoľvek otázok alebo projektov.

Komentáre
Avatar
Andrej Farkaš:24.10.2013 7:46

Super článok. Už len to dostať do praxe :-)

Odpovedať
24.10.2013 7:46
Live. Love. Learn.
Avatar
Pavel Polívka:12.7.2014 6:37

Výborný článek. Díky za něj!

 
Odpovedať
12.7.2014 6:37
Avatar
Marian Benčat:28.1.2016 14:29

Bohužel nemohu s některýma věcma souhlasit... s některýma nesouhlasím dosti hrubě.

"Pokud používáme ORM (Objektově-Relační Mapování), korespondují modely přímo s databázovými tabulkami. Máme tedy model Uzivatel, Komentar nebo Clanek. Instance modelů obsahují samozřejmě atributy z databáze. "

Modely rozhodně neodpovídají databázi. Model je logika aplikace a ta by měla být na 100% odstíněna o tom, jak jsou uloženy data - většinou se k tomu používá nějaký typ "storu" - repozitáře. Takže model NESMÍ vědět o tom, jak jsou data uložena - z pohledu modelu , on využívá pouze metody určitého abstraktního storu, ten je poté implementován, nějakou DAL vrstvou.

Model je většinou implementován jako nějaká fasáda - servisa, chcete-li. Ta servisa poté využívá storu k operacím, které jsou spokjeny s daty, (logika zustava v modelu - ve fasádách - ta si také řídí UOW).

Pokud chcete říct, že model odpovídá databázi, dopouštíte se hodně chyb a přivede vám to opravud hodně problémů, především co se týče testování aplikace, modularity a responsibility.

Vy se snažíte používat tzv. Rich Domain model, který je zcela správně co se týče objektového návrhu, ale porušuje defakto úplně všechny SOLID pravidla a to opravdu velmi velmi silně. Oproti tomu Aenemic domain model (který nedodržuje stirktně OOP - plní SOLID v každém ohledu naprosto ideálně). Aenemic model je právě rozdělení aplikace na N-tier aplikaci (Frontend, servisy, dal, db,..).

Je to samo o sobě ironie - SOLID /což je poučka jak dělat OOP aplikace /, zde dokazuje, že je lepší použít non-OOP přístup, protože OOP samotný SOLID narušuje.

Doporučuji vám opravdu velmi silně NErvat do modelu všechno (db přístup, story, logiku), přiděláte si tím hodně problémů a nic vám to nepřinese, - tedy kromě toho, že se budete moci poplácat, že ej to správně OOP.

Na závěr bych rád řekl, že oop by jste měl používat tam kde vám nehází klacky pod nohy (nebo nebude házet).

*ps - modely by rozhodne nemely obsahovat 1:1 atributy jako jsou v databazi, to je hloupost. Jedna se opet o implementacni detail databaze, ktery vy vedome leakujete z vrstvy DALu.

Editované 28.1.2016 14:31
Odpovedať
28.1.2016 14:29
Totalitní admini..
Avatar
JOF
Tvůrce
Avatar
Odpovedá na Marian Benčat
JOF:28.1.2016 23:15

Ahoj,

spoustě těch slov vůbec nerozumím :-( , ale to je samozřejmě mojí neznalostí. Chtěl bych jen říct, že mi terminologie v MVC nepřijde úplně jednotná. Modelem v DAL se často označují třídy, které jsou 1:1 s tabulkami v DB (např. u code first přístupu). Modely v business vrstvě, nad kterými se provádí veškerá logika, už nemusí být 1:1 s DB. Logika aplikace také nemusí být přímo v modelech, ale třeba v servisách nebo managerech. V aplikační vrstvě jsou mody často DTOčka z business vrstvy. Jako modely zde také bývají označovány ViewModely, které jsou předávány pohledům.

Takže já zase nesouhlasím s tvrzením, že "Model je logika aplikace..."

 
Odpovedať
28.1.2016 23:15
Avatar
Odpovedá na JOF
Marian Benčat:28.1.2016 23:25

souhlasim ze je to zavadejici, S necim souhlasim, s necim ne.

I U code first je v DALu entita správně svobodná od Databáze - přináší to spoustu výhod, běžně tedy se pro code first použije tedy nějaké DTOčko, ale to neví o tom, že existuje "nějaká databáze" - je to obecný objekt - přepravka pro data, které se pohybují po aplikaci. a konfigurace (mapovani) se deje mimo toto DTO. tedy DTO muze byt uplne jine nez databaze (a je tomu spravne) Já osobně za MODEL v MVC považuji pouze a jenom "core" - servisy, fasády..ale to je muj nazor.

Ze širokého hlediska lze skutečně říkat model 10ti ruznym vecem...Pokud je ale v clanku myslen MODEL = entita v DALu, tak to nic nemeni na tom, ze je spatne pokud je natvrdo navazana na konkretni tabulky ;-) od toho je to Code first - nás "nezajímá" jak je to v DB, my prostě máme objekty a jak se to udělá na pozadí - to je na konfiguraci.

Odpovedať
28.1.2016 23:25
Totalitní admini..
Avatar
Odpovedá na Marian Benčat
Neaktivní uživatel:29.1.2016 0:05

Já sám třeba nesnáším tu dnešní přílišnou komplexnost těchto věcí. Souhlasím s tím, že model by vůbec neměl vědět o databázi a líbí se mě přístup Entity Frameworku, kde jsou modely obyčejné třídy a o databázi se stará DbContext (podle dnešního názvosloví nejspíš repozitář). Nechápu, proč i takhle se vytváří různé viewmodely, dokonce někteří dělají reposizář ještě nad DbContext... Na druhou stranu chápu data transfer objecty, když jsou nutné pro předávání specifických dat nebo na odstranění kruhové závislosti např. při serializaci na JSON (to nastane když závislý objekt odkazuje na svého rodiče a ten zase odkazuje zpět např. přes nějakou kolekci)

Odpovedať
29.1.2016 0:05
Neaktivní uživatelský účet
Avatar
Odpovedá na Neaktivní uživatel
Marian Benčat:29.1.2016 8:21

Ono je to naopak dosti pochopitelné. View modely mít naopak chcete. Jednak vám automaticky osetri věci jako je overbinding a také dp nich nandate logiku pro ui. Já třeba mám vlastní knihovnu, že na základě view modelu se mi automaticky generuje formulář a to na bootstrapu, poháněný angularem, ng-messages a bootstrap tooltipem a plno dalších věcí. Tyto informace třeba v dto nemají co dělat.na ani tam být nemůžou.. Dto máte v nějaké class library ,,shared" tam prostě mít referenci na mvc nemůžete.

Ohledně repozitory.. Db context je sám o sobě kombinace repozitare a uow, ale toto je věc kterou rozhodně nechcete exposovat z dálu.. Rozhodně nechcete vracet něco jako dbset.

Odpovedať
29.1.2016 8:21
Totalitní admini..
Avatar
Odpovedá na Marian Benčat
Neaktivní uživatel:29.1.2016 11:06

Tu poslední větu jsem nějak nepochopil :-D. Ale já třeba nevidím problém v předávání modelu to pohledu (v ASP.NET), když k tomu i VS přímo vybízí.

Odpovedať
29.1.2016 11:06
Neaktivní uživatelský účet
Avatar
Odpovedá na Neaktivní uživatel
Marian Benčat:29.1.2016 11:21

Omlouvám se, psal jsem to už v posteli a druhou rukou hladil přítelkyni na zádech, takže jsem nemohl efektivně odepisovat :D

Ano..i základní templaty bohužel mají složku models, do které rvou například modely z IdentityFrameworku a i viewmodely, vše do složky models.. dokonce i ViewModels jsou nazývány také jako View Specific Models,.. což je i samotným microsoftem považováno - že udělali blbost.

Předávání modelu do pohledu je špatně z několika důvodů, kde některé hned zmíním:

  1. Pokud chcete ovlivnit výslednou stránku - view a chcete to ovlivnit na základě view modelu, musíte upravit model - což je absolutně špatně.. model jsou dat aaplikace, proč bych je já měl modifikovat na zákaldě toho, že chci mít jiné view?
  2. pokud je model něco co má odpovídat DB, tak máte zaděláno na velký průser s nutností velkého refaktoringu kódu
  3. máte automaticky vyřešený problém overbindingu a validace
  4. V DTO nesmíte mít informace o UI validaci / zobrazení atp. pokud to tam máte, předem jste odkázal celý svůj solution na to, že na frontendu bude MVC... jelikož musíte použít různé data anotace a další reference na MVC

K poslendí větě:

Ohledně repozitory.. Db context je sám o sobě kombinace repozitare a uow, ale toto je věc kterou rozhodně nechcete exposovat z dálu.. Rozhodně nechcete vracet něco jako dbset.

DBContext entity frameworku je implementován jako repository pattern (DBSet) a UOW (SaveChanges()).
Pokud máte le složité dotazy, dáte je buďto do repozitáře, nebo do query objectu (ideálně máte prostě generický repozitář, od kterého dědíte a v podědělné třídě můžete mít další metody - queries). Co ale nesmíte udělat je mít v repozitáři něco takovéhoto:

public IQueryable<Article> GetMyArticle () {
return dbcontext.Arti­cles.Where(..­.);
}

Jelikož vracíte IQueryable db contextu - tzv. leakujete do vyšší vrstvy (servisa) informace o DALu (DBContext) = timto jste se predem omezil na to, ze pokud budete chtit DAL zamenit za nejaky mockup (testovani), nebo udelat nejakou strategy / pripadne zmenit implementaci,...

Tak musíte reimplementovat jak kolík ;-)

Odpovedať
29.1.2016 11:21
Totalitní admini..
Avatar
Odpovedá na Marian Benčat
Neaktivní uživatel:29.1.2016 11:28

Ohledně repository, na stackoverflow i jedne teda panuje názor, že vytvářet nějakou vrstvu nad DbClntextwm je zbytečné a nedoporučuje se. A ohledně DTO a ViewModelu... nikdy jsem neviděl žádnou implementaci, ani něco jako getting started takže si to moc nedovedu představit, například jak by měl ovlivňovat view. Pro mě je všechna prezentační logika ve viewu a v modelu data/business logika.

Odpovedať
29.1.2016 11:28
Neaktivní uživatelský účet
Robíme čo je v našich silách, aby bola tunajšia diskusia čo najkvalitnejšia. Preto do nej tiež môžu prispievať len registrovaní členovia. Pre zapojenie sa do diskusie sa zaloguj. Ak ešte nemáš účet, zaregistruj sa, je to zadarmo.

Zatiaľ nikto nevložil komentár - buď prvý!