Način MVC: Model View poskuša nadzorovati krmilnik, ki je trenutno glavni način in se uporablja kot osnovni način vstopa v strežniško programsko opremo za učenje in obvladovanje, medtem ko glavni okvir Struts 1/2 JSF Wicket v osnovi podpira način MVC.
Vendar pa zaradi stalne popularizacije B/S in internetnih aplikacij, Web 2.0 in številnih pogostih interaktivnih aplikacij, kot so družbena omrežja in igre, relativno statični način MVC ni več primeren za zelo interaktivne in vedenjsko usmerjene aplikacije.
Modeliranje DDD domene samo po sebi posveča več pozornosti strukturi, njegova entitetna vrednost, objekt in strežnik sta prav tako nekakšna strukturna delitev, vendar ne poudarja pomena nalog in vedenja objektov, kar je edina razlika med objekti in podatkovnimi bazami.
Nasprotno,Oblikovanje predmetov: vloge, odgovornosti in sodelovanjaKnjiga predlaga, da predmet dejansko igra določeno vlogo in da je vloga odgovorna, nato pa bo določeno interaktivno vedenje implementirano v določenem kontekstu scene, kar je bilo v celoti obravnavano v Jdonu:
DCI, domenski model, nekaj idej za domenske dogodke
Asinhrono arhitekturno razmišljanje: Implementirajte modeliranje domene z Akko
Knjiga povzema štiri glavne slabosti centraliziranih krmilnikov, pri čemer MVC-jevi krmilniki dejansko spadajo v ta centralizirani slog krmilnika:
1. Kontrolna logika je lahko preveč zapletena. Krmilniki so lahko zapleteni, pogosto pa mnogi pišejo poslovno kodo v Strutsovih akcijskih krmilnikih.Vse akcije so v akcijah, nekatere akcije pa so skoraj tisoče vrstic.
2. Kontrolorji lahko postanejo odvisni od vsebine imetnikov informacij. Nadzorniki postanejo odvisni od podatkovnih centrov ali baz podatkov, nadzorniki počnejo veliko stvari, kar pomeni, da domenski objekti naredijo zelo malo, in kontrolor ne bo le na koncu naredil kaj, ampak bo tudi odločal o strateških stvareh, poleg tega pa so povezana s taktičnimi vprašanji, kot so kako to izvesti in kako to izvediti.
3. Objekti se lahko posredno povežejo z dejanji njihovega krmilnika. Objekti so posredno povezani preko dejanj krmilnika, en objekt se poizveduje v krmilniku, nato pa se kopira na drug objekt, oba objekta pa sta povezana.
4. Edino zanimivo delo se opravi v kontrolerju.
Krmilnik MVC je nekakšen način mediatorja, hkrati pa tudi centraliziran kontroler, kar je glavna razlika od načina opazovalca: način mediatorja zajema komunikacijo, medtem ko ima decentralizirana komunikacija z vidika komunikacije tudi krmilnik svoje notranje pomanjkljivosti, ki jih je enostavno spremeniti v velik in popolnoma povezan koncentrator, vse to je zaOOTo ni tolerirano.
Arhitektura DCIGre za nov koncept, ki se je pojavil šele pred kratkim in gleda na programsko opremo z nove perspektive, kar sovpada z in ima prav glede oblikovanja, ki temelji na dolžnostiDDDRazvoj in izboljšave.
DCI je okrajšava za Data Context Interactions, njegov pomemben prispevek pa je predstavitev koncepta prizorov, ki ni omenjen v knjigi Duty-Driven Development, ki le zanika MVC, razkriva njegove težave in ne predlaga alternativDCIGre za alternativno arhitekturo MVC, DCI pa MVC nadomešča s scenariji za zamenjavo krmilnikov, kot je prikazano na spodnji sliki (slika je iz).Izvirna angleščinaDCI Architecture: A New Vision of Object-Oriented Programming)：
Prizor dejansko izkoplje nekaj kontrol in modelov iz MVC ter jih ponovno sestavi v obliki prizorov z liki. To je nov kot, ki je popolnoma drugačen od upoštevanja načina prometa (MVC), ki je bolj usklajen s tem kotomOO。
Nedavno je nekdo to izpostavilKontekst prizora je nova vrsta objekta, sceno ni mogoče le zamenjatiSOASpletne storitve lahko prav tako nadomestijo MVC krmilnike.
Osebno menim, da bo nova hierarhična arhitektura v prihodnosti izgledala takole:
Ogled --> Kontekst ---> domenski model ---> komponenta/repozitorij
Način prometnega prometa je mrtev.
|
Objavljeno na 6. 12. 2014 22:17:21
|
|
|
|
Objavljeno na 7. 12. 2014 17:23:04
