MVC-läge: Model View försöker styra kontrollern, vilket är det nuvarande mainstream-läget, och används som det grundläggande läget för serverprogramvaruinmatning för att lära sig och bemästra, och det vanliga ramverket Struts 1/2 JSF Wicket stöder i princip MVC-läge.
Men med den ständiga populariseringen av B/S- och internetapplikationer, Web 2.0 och ett stort antal frekventa interaktiva applikationer såsom sociala medier och spel, är det relativt statiska MVC-läget inte längre lämpligt för mycket interaktiva och beteendeinriktade applikationer.
DDD-domänmodellering ägnar i sig mer uppmärksamhet åt struktur, dess entity value-objekt och server är också en slags strukturell uppdelning, men den betonar inte vikten av objektuppgifter och beteenden, och detta är den enda skillnaden mellan objekt och databaser.
Tvärtom,Objektdesign: Roller, ansvar och samarbetenBoken föreslår att objektet faktiskt spelar en viss roll, och rollen är ansvarig, och sedan implementeras ett visst interaktivt beteende i en viss scenkontext, vilket har diskuterats fullt ut i Jdon:
DCI, domänmodell, några idéer för domänhändelser
Asynkront arkitektoniskt tänkande: Implementera domänmodellering med Akka
Boken sammanfattar de fyra största nackdelarna med centraliserade kontroller, och MVC:s styrenheter tillhör faktiskt denna centraliserade kontrollerstil:
1. Styrlogik kan bli alltför komplex. Controllers kan bli komplicerade, och det är vanligt att många skriver affärskod i Struts Action-kontroller.Alla handlingar är i handlingar, och vissa handlingar är nästan tusentals rader.
2. Controllers kan bli beroende av informationsinnehavarnas innehåll. Controllers blir beroende av informationsdatacenter eller databaser, controllers gör mycket, vilket innebär att domänobjekt gör väldigt lite, och controllern gör inte bara vad i slutändan, utan beslutar också strategiska saker, men det är också kopplat till taktiska frågor som hur man gör det och hur man implementerar det.
3. Objekt kan kopplas indirekt genom sin kontrollörs handlingar. Objekt kopplas indirekt ihop genom kontrollerns handlingar, ett objekt frågas i kontrollenheten och kopieras sedan till ett annat objekt, och de två objekten kopplas tillsammans.
4. Det enda intressanta arbetet görs i kontrollenheten.
Styrenheten för MVC är en slags Mediatorläge, men också en centraliserad regulator, det är den största skillnaden från observatörsläget: Mediatorläget kapslar in kommunikationen, medan observatören decentraliserar kommunikation, ur kommunikationssynpunkt, kontrollern har också sina inneboende brister, lätt att bli en stor och fullt kopplad koncentrator, dessa är alla förOODet tolereras inte.
DCI-arkitekturDet är ett nytt koncept som nyligen har uppstått och ser på mjukvara ur ett nytt perspektiv, vilket sammanfaller med och är rätt i pliktdriven designDDDutveckling och förbättring.
DCI är förkortningen för Data Context Interactions, och dess viktiga bidrag är att föreslå konceptet scener, vilket inte nämns i boken Duty-Driven Development, som endast förnekar MVC, avslöjar dess problem och inte föreslår alternativDCIDet är MVC:s alternativa arkitektur, och DCI ersätter MVC med scenarier för att ersätta styrenheter, som visas i figuren nedan (bilden är från).Originalengelska TheDCI Architecture: A New Vision of Object-Oriented Programming)：
Scenen gräver faktiskt fram några av kontrollerna och modellerna i MVC och sätter ihop dem igen i form av karaktärsscener. Detta är en ny vinkel som skiljer sig helt från MVC-lägesövervägandet, vilket ligger mer i linje med denna vinkelOO。
Nyligen har någon tagit upp detScene Context är en ny objekttyp, scenen kan inte bara ersättasSOAWebbtjänster kan också ersätta MVC-kontroller.
Personligen tror jag att den nya hierarkiska arkitekturen kan se ut så här i framtiden:
Visa --> kontext ---> domänmodell ---> komponent/respositorium
MVC-läget är dött.
|
Publicerad på 2014-12-06 22:17:21
|
|
|
|
Publicerad på 2014-12-07 17:23:04
