MVC-tilstand: Model View forsøger at styre controlleren, som er den nuværende mainstream-tilstand, og bruges som den grundlæggende tilgang til serversoftware, som man skal lære og mestre, og det almindelige framework Struts 1/2 JSF Wicket understøtter grundlæggende MVC-tilstand.
Men med den løbende udbredelse af B/S og internetapplikationer, Web 2.0 og et stort antal hyppige interaktive applikationer som sociale medier og spil, er den relativt statiske MVC-tilstand ikke længere egnet til meget interaktive og adfærdsorienterede applikationer.
DDD-domænemodellering lægger i sig selv mere vægt på struktur; dens entity value-objekt og server er også en slags strukturel opdeling, men den lægger ikke vægt på vigtigheden af objektopgaver og adfærd, og det er den eneste forskel mellem objekter og databaser.
Tværtimod,Objektdesign: Roller, ansvar og samarbejderBogen foreslår, at objektet faktisk spiller en bestemt rolle, og rollen er ansvarlig, og derefter vil en bestemt interaktiv adfærd blive implementeret i en bestemt scenekontekst, som er blevet grundigt diskuteret i Jdon:
DCI, domænemodel, nogle idéer til domænebegivenheder
Asynkron arkitektonisk tænkning: Implementér domænemodellering med Akka
Bogen opsummerer de fire største ulemper ved centraliserede controllere, og MVC's controllere tilhører faktisk denne centraliserede controller-stil:
1. Kontrollogik kan blive alt for kompleks. Controllere kan blive komplicerede, og det er almindeligt, at mange skriver forretningskode i Struts' Action-controllere.Alle handlinger er i handlinger, og nogle handlinger er næsten tusindvis af linjer.
2. Controllere kan blive afhængige af indholdet, som er indeholdt af information. Controllere bliver afhængige af informationsdatacentre eller databaser, controllere gør mange ting, hvilket betyder, at domæneobjekter gør meget lidt, og controlleren vil ikke kun gøre hvad i sidste ende, men også beslutte strategiske ting, men også kombineret med taktiske spørgsmål som, hvordan det skal gøres og implementeres.
3. Objekter kan blive koblet indirekte gennem deres kontrollers handlinger. Objekter kobles indirekte sammen gennem controllerens handlinger, ét objekt forespørges i controlleren og kopieres derefter til et andet objekt, og de to objekter kobles sammen.
4. Det eneste interessante arbejde udføres i controlleren.
Controlleren af MVC er en slags Mediator-tilstand, men også en centraliseret controller, det er den væsentligste forskel fra observatør-tilstanden: Mediator-tilstanden indkapsler kommunikation, mens observatøren decentraliserer kommunikation, og fra et kommunikationssynspunkt har controlleren også sine iboende fejl, let at blive en stor og fuldt koblet koncentrator, disse er alle forOODet tolereres ikke.
DCI-arkitekturDet er et nyt koncept, der først for nylig er opstået og ser på software fra et nyt perspektiv, hvilket stemmer overens med og er rigtigt i forhold til duty driven designDDDudvikling og forbedring.
DCI er forkortelsen for Data Context Interactions, og dens vigtige bidrag er at fremføre konceptet scener, som ikke nævnes i bogen Duty-Driven Development, der kun benægter MVC, afslører dets problemer og ikke foreslår alternativerDCIDet er MVC's alternative arkitektur, og DCI erstatter MVC med scenarier, der erstatter controllere, som vist i figuren nedenfor (billedet er fra).Originalengelsk TheDCI Architecture: A New Vision of Object-Oriented Programming)：
Scenen graver faktisk nogle af kontrollerne og modellerne i MVC frem og samler dem igen i form af karakterscener. Dette er en ny vinkel, der er helt anderledes end MVC-tilstanden, som passer bedre til denne vinkelOO。
For nylig har nogen taget det opScene Context er en ny objekttype, scenen kan ikke blot erstattesSOAWebtjenester kan også erstatte MVC-controllere.
Personligt tror jeg, at den nye hierarkiske arkitektur måske vil se sådan ud i fremtiden:
View --> kontekst ---> domænemodel ---> komponent/repository
MVC-tilstand er død.
|
Opslået på 06/12/2014 22.17.21
|
|
|
|
Opslået på 07/12/2014 17.23.04
