Režim MVC: Model View sa snaží ovládať ovládač, čo je aktuálny mainstreamový režim, a používa sa ako základný spôsob zadávania softvéru na server na učenie a zvládnutie, pričom hlavný framework Struts 1/2 JSF Wicket v podstate podporuje režim MVC.
Avšak s neustálou popularizáciou B/S a internetových aplikácií, Webu 2.0 a veľkého množstva častých interaktívnych aplikácií, ako sú sociálne médiá a hry, už relatívne statický režim MVC nie je vhodný pre vysoko interaktívne a behaviorálne aplikácie.
Modelovanie DDD domény samo o sebe venuje väčšiu pozornosť štruktúre, jeho hodnota entity, objekt a server sú tiež akýmsi štrukturálnym rozdelením, ale nezdôrazňuje dôležitosť úloh a správania objektov, a to je jediný rozdiel medzi objektmi a databázami.
Naopak,Dizajn objektov: Úlohy, zodpovednosti a spolupráceKniha navrhuje, že objekt skutočne hrá určitú úlohu a táto úloha je zodpovedná, a potom bude implementované určité interaktívne správanie v určitom kontexte scény, čo bolo podrobne rozobrané v Jdonovi:
DCI, doménový model, niekoľko nápadov pre doménové udalosti
Asynchrónne architektonické myslenie: Implementujte doménové modelovanie pomocou Akka
Kniha zhrňuje štyri hlavné nevýhody centralizovaných regulátorov a ovládače MVC v skutočnosti patria do tohto štýlu centralizovaného ovládača:
1. Riadiaca logika môže byť príliš zložitá. Ovládače môžu byť zložité a je bežné, že mnohí ľudia píšu obchodný kód v Struts' Action controlleroch.Všetky akcie sú v akciách a niektoré akcie majú takmer tisíce riadkov.
2. Kontrolóri sa môžu stať závislými od obsahu držiteľov informácií. Kontrolóri sa stávajú závislými od dátových centier alebo databáz informácií, kontrolóri robia veľa vecí, čo znamená, že doménové objekty robia veľmi málo, a kontrolór nielenže nakoniec robí čo a čo robí, ale aj rozhoduje o strategických veciach, ale v kombinácii s taktickými otázkami, ako to robiť a ako to implementovať.
3. Objekty sa môžu spojiť nepriamo prostredníctvom akcií ich kontroléra. Objekty sú nepriamo prepojené akciami kontroléra, jeden objekt sa dotazuje v kontroléri a potom sa skopírova k inému objektu, pričom oba objekty sú navzájom prepojené.
4. Jediná zaujímavá práca sa robí v ovládači.
Ovládač MVC je akýsi režim Mediátora, ale aj centralizovaný ovládač, čo je hlavný rozdiel oproti režimu pozorovateľa: režim Mediátora zahŕňa komunikáciu, zatiaľ čo decentralizovaná komunikácia pozorovateľa, z hľadiska komunikácie, má aj ovládač svoje vnútorné nedostatky, ľahko sa môže stať veľkým a plne prepojeným koncentrátorom, ktoré sú všetky preOONie je to tolerované.
Architektúra DCIJe to nový koncept, ktorý sa objavil len nedávno a pozerá sa na softvér z novej perspektívy, čo súvisí s návrhom riadeným povinnosťou a má pravduDDDVývoj a zlepšovanie.
DCI je skratka pre Data Context Interactions a jeho dôležitým prínosom je predstavenie konceptu scén, ktorý nie je spomenutý v knihe Duty-Driven Development, ktorá len popiera MVC, odhaľuje jeho problémy a nenavrhuje alternatívyDCIIde o alternatívnu architektúru MVC a DCI nahrádza MVC scenármi na nahradenie kontrolérov, ako je znázornené na obrázku nižšie (obrázok je z).Pôvodná angličtinaDCI Architecture: A New Vision of Object-Oriented Programming)：
Scéna vlastne vyberie niektoré ovládacie prvky a modely z MVC a znovu ich poskladá do podoby scén s postavami. Toto je nový uhol, ktorý je úplne odlišný od úvahy o MVC režime, ktorý je bližšie tomuto uhluOO。
Nedávno to niekto spomenulKontext scény je nový typ objektu, scéna sa nedá len nahradiťSOAWebové služby môžu tiež nahradiť MVC kontroléry.
Osobne si myslím, že nová hierarchická architektúra môže v budúcnosti vyzerať takto:
Zobraziť --> Kontext ---> doménový model ---> komponent/repozitórium
Režim MVC je mŕtvy.
|
Zverejnené 6. 12. 2014 22:17:21
|
|
|
|
Zverejnené 7. 12. 2014 17:23:04
