MVC mód: A Model View megpróbálja irányítani a vezérlőt, ami a jelenlegi mainstream mód, és a szerver szoftver alapvető játékmódjaként szolgál a tanuláshoz és mesterhez, míg a mainstream keretrendszer Struts 1/2 JSF Wicket alapvetően támogatja az MVC módot.
Azonban a B/S és az internetes alkalmazások, a Web 2.0 folyamatos népszerűsítése, valamint a sok gyakori interaktív alkalmazás, például a közösségi média és játékok miatt a viszonylag statikus MVC mód már nem alkalmas nagyon interaktív és viselkedésorientált alkalmazásokhoz.
A DDD domain modellezés maga nagyobb figyelmet fordít a szerkezetre, az entitásérték, objektum és szerver is egyfajta strukturális felosztás, de nem hangsúlyozza az objektum kötelezettségeinek és viselkedésének fontosságát, és ez az egyetlen különbség az objektumok és adatbázisok között.
Épp ellenkezőleg,Objektumtervezés: Szerepek, felelősségek és együttműködésekA könyv azt javasolja, hogy az objektum valójában egy bizonyos szerepet tölt be, és a szerep felelős, majd egy bizonyos interaktív viselkedést valósítanak meg egy adott jelenetbeli kontextusban, amit a Jdon részletesen tárgyal:
DCI, domain modell, néhány ötlet tartományeseményekhez
Aszinkron architekturális gondolkodás: A domain modellezés megvalósítása Akkával
A könyv összefoglalja a központosított vezérlők négy fő hátrányát, és az MVC vezérlői valójában ebbe a központosított vezérlő stílusba tartoznak:
1. Az irányítási logika túl bonyolult lehet. A kontrollerek bonyolultak lehetnek, és sokan gyakran írnak üzleti kódot a Struts Action vezérlőivel.Minden akció akcióban van, és néhány akció majdnem több ezer vonalból áll.
2. A vezérlők függhetnek az információbirtokolók tartalmától. A vezérlők információs adatközpontoktól vagy adatbázisoktól függnek, a vezérlők sok mindent elvégeznek, ami azt jelenti, hogy a domain objektumok nagyon keveset csinálnak, és a vezérlő nemcsak a végén mit csinál, hanem stratégiai dolgokat is dönt, de taktikai kérdésekkel, például hogyan kell és hogyan valósítsa meg.
3. Az objektumok közvetve kapcsolódhatnak a vezérlőjük cselekedeteihez. Az objektumok közvetve kapcsolódnak egymáshoz a vezérlő műveleteivel, az egyik objektumot lekérdezik a vezérlőben, majd másolják egy másik objektumba, és a két objektum összekapcsolódik.
4. Az egyetlen érdekes munka a kontrollerben történik.
Az MVC vezérlője egyfajta közvetítő mód, de egyben központosított vezérlő is, ez a fő különbség a megfigyelő módhoz képest: a közvetítő mód magában foglalja a kommunikációt, míg a megfigyelő decentralizált kommunikációt – a kommunikáció szempontjából a vezérlőnek is vannak veleszületett hibái, könnyen nagy és teljesen kapcsolt koncentrátorrá válhat – ezek mind a következőkÓEzt nem tűrik.
DCI architektúraEz egy új koncepció, amely csak nemrég jelent meg, és új szemszögből vizsgálja a szoftvereket, ami egybeesik a kötelességvezérelt tervezéssel és helyes a tervezésbenDDDfejlesztés és fejlesztés.
A DCI a Data Context Interactions rövidítése, és fontos hozzájárulása a jelenetek fogalmának feltárása, amelyet a Duty-Driven Development könyv nem említ, amely csak tagadja az MVC-t, feltárja annak problémáit, és nem javasol alternatívákatDCIEz az MVC alternatív architektúrája, és a DCI az MVC-t olyan forgatókönyvekkel helyettesíti, amelyek vezérlőket helyettesítenek, ahogy az alábbi ábrán is látható (a kép onnan).Eredeti angol TheDCI Architecture: A New Vision of Object-Oriented Programming)：
A jelenet valójában előásja az MVC-ben található irányításokat és modelleket, és karakterjelenetek formájában összerakja őket. Ez egy új szög, amely teljesen eltér az MVC mód szempontjától, amely inkább ehhez a szöghez illeszkedikÓ。
Nemrég valaki felvetette eztA Scene Context egy új objektumtípus, a jelenet nemcsak helyettesíthetőSOAWebes szolgáltatások kiválthatják az MVC vezérlőket is.
Személy szerint úgy gondolom, hogy az új hierarchikus építészet a jövőben így fog kinézni:
View --> Context ---> Domain Model ---> Component/Respository
Az MVC mód halott.
|
Közzétéve 2014. 12. 06. 22:17:21
|
|
|
|
Közzétéve 2014. 12. 07. 17:23:04
