MVC-modus: Model View prøver å kontrollere kontrolleren, som er den nåværende hovedstrømsmodusen, og brukes som den grunnleggende modusen for å lære og mestre serverprogramvare, og det vanlige rammeverket Struts 1/2 JSF Wicket støtter i hovedsak MVC-modus.
Men med den kontinuerlige populariseringen av B/S og Internett-applikasjoner, Web 2.0 og et stort antall hyppige interaktive applikasjoner som sosiale medier og spill, er den relativt statiske MVC-modusen ikke lenger egnet for svært interaktive og atferdsorienterte applikasjoner.
DDD-domenemodellering i seg selv legger mer vekt på struktur, dens entity value-objekt og server er også en slags strukturell inndeling, men den legger ikke vekt på viktigheten av objektoppgaver og atferd, og dette er den eneste forskjellen mellom objekter og databaser.
Tvert imot,Objektdesign: Roller, ansvar og samarbeidBoken foreslår at objektet faktisk spiller en bestemt rolle, og rollen er ansvarlig, og deretter vil en viss interaktiv atferd bli implementert i en bestemt scenekontekst, som har blitt grundig diskutert i Jdon:
DCI, domenemodell, noen ideer til domenehendelser
Asynkron arkitektonisk tenkning: Implementer domenemodellering med Akka
Boken oppsummerer de fire største ulempene med sentraliserte kontrollere, og MVCs kontrollere tilhører faktisk denne typen sentralisert kontroller:
1. Kontrolllogikk kan bli altfor kompleks. Controllere kan bli kompliserte, og det er vanlig at mange skriver forretningskode i Struts' Action-controllere.Alle handlinger er i handlinger, og noen handlinger er nesten tusenvis av linjer.
2. Controllere kan bli avhengige av innholdet til informasjonsholdere. Controllere blir avhengige av informasjonsdatasentre eller databaser, controllere gjør mye, noe som betyr at domeneobjekter gjør svært lite, og controlleren vil ikke bare gjøre hva til slutt, men også bestemme strategiske ting, men også kombinert med taktiske spørsmål som hvordan det skal gjøres og hvordan det skal implementeres.
3. Objekter kan bli koblet indirekte gjennom handlingene til sin kontroller. Objekter kobles indirekte sammen gjennom kontrollerens handlinger, ett objekt spørres i kontrolleren, og kopieres deretter til et annet objekt, og de to objektene kobles sammen.
4. Det eneste interessante arbeidet gjøres i kontrolleren.
Kontrolleren til MVC er en slags Mediator-modus, men også en sentralisert kontroller, det er hovedforskjellen fra observatørmodus: Mediator-modusen kapsler inn kommunikasjon, mens observatøren desentraliserer kommunikasjon, fra et kommunikasjonsperspektiv har controlleren også sine iboende feil, lett å bli en stor og fullt koblet konsentrator, alt dette er forOODet tolereres ikke.
DCI-arkitekturDet er et nytt konsept som først nylig har dukket opp og ser på programvare fra et nytt perspektiv, noe som sammenfaller med og er riktig når det gjelder pliktdrevet designDDDUtvikling og forbedring.
DCI er forkortelsen for Data Context Interactions, og dens viktige bidrag er å fremme konseptet scener, som ikke nevnes i boken Duty-Driven Development, som bare benekter MVC, avdekker problemene og ikke foreslår alternativerDCIDet er den alternative arkitekturen til MVC, og DCI erstatter MVC med scenarier for å erstatte kontrollere, som vist i figuren under (bildet er fra).Original engelsk TheDCI Architecture: A New Vision of Object-Oriented Programming)：
Scenen graver faktisk frem noen av kontrollene og modellene i MVC og setter dem sammen igjen i form av karakterscener. Dette er en ny vinkel som er helt annerledes enn MVC-modusvurderingen, som er mer i tråd med denne vinkelenOO。
Nylig har noen tatt det oppScene Context er en ny objekttype, scenen kan ikke bare erstattesSOAWebtjenester kan også erstatte MVC-kontrollere.
Personlig tror jeg at den nye hierarkiske arkitekturen kan se slik ut i fremtiden:
View --> kontekst ---> domenemodell ---> komponent/repositorium
MVC-modus er død.
|
Publisert på 06.12.2014 22:17:21
|
|
|
|
Publisert på 07.12.2014 17:23:04
