MVC模式已死

                   
banq 10-04-09

MVC模式:Model模型 View试图 Control控制器,是目前主流模式,被当作服务器软件入门基本模式学习和掌握,主流框架Struts 1/2 JSF Wicket基本都顺理成章支持MVC模式。

但是,随着时间推移,MVC模式也暴露出大量缺点,因为MVC模式本质上是一个结构型模式,结构模式相比行为模式而言,实际就是静止的,相对固定的,而随着B/S和互联网应用不断普及,Web 2.0和社会化媒体 以及游戏等大量频繁交互应用普及,相对静止的MVC模式已经不适合高度交互注重行为的应用了。

DDD领域建模本身比较重视结构,它的实体 值对象和服务器是也是一种结构划分,但是没有强调对象职责行为的重要性,而这是对象和数据库唯一的区别,当然其上下文场景概念的提出,也可以认为体现了对角色和场景的重视,但远远不够。

相反,对象设计:角色、责任和协作"(Object Design: Roles, Responsibilities, and Collaborations))一书提出职责驱动开发,将对象行为上升为重点,提出了对象其实是在扮演某种角色,而角色是有职责的,然后会在一定场景上下文环境中实施一定交互行为,这些已经在Jdon进行了充分讨论:
DCI,领域模型,领域事件的一些想法
异步架构思维:使用Akka实现领域建模

该书总结了集中式控制器4大缺点,MVC的控制器实际就属于这种集中式控制器风格:

1.Control logic can get overly complex. 控制器会变得复杂,很多人在Struts的Action控制器中写业务代码已经变得很常见,所有的操作都在action中,有的action都几乎上千行了.

2.Controllers can become dependent on information holders' contents.控制器变得依赖信息数据中心或数据库了,控制器做很多事情,意味着领域对象就做很少事情,控制器最后不是只会做什么,决定战略性的事情,也和怎么做,如何实现等战术问题耦合。

3.Objects can become coupled indirectly through the actions of their controller. 对象将间接地通过控制器的action耦合在一起,一个对象在控制器中查询获得,然后复制给另外一个对象,这两个对象就耦合在一起。

4.The only interesting work is done in the controller.唯一有趣的工作是做控制器,Responsibilities职责被吸进控制器对象,只将一些行为留给角色模型完成,重要的事情都集中在控制器中了。

MVC的控制器是Mediator模式一种,也属于一种集中式控制器,它与观察者模式重大区别是:Mediator模式封装了通讯,而Observer分散通讯,从通讯角度来看,控制器也有其固有的缺陷,容易变成大而全高度耦合的集中器,这些都是为OO所不容。

DCI架构是最近才兴起的新概念,它从一个全新角度来看待软件,与职责驱动设计不谋而合,同时也是对DDD的发展和完善。

DCI是数据Data 场景Context 交互Interactions的简称,它重要贡献是提出了场景这个概念,而这点是职责驱动开发一书没有提及,该书只是否定了MVC,揭露其问题,没有提出替代方案,而DCI正是MVC的替代架构,DCI替代MVC 用场景替代控制器应该是大势所趋,如下图(图来自原文英文The DCI Architecture: A New Vision of Object-Oriented Programming):

场景其实将MVC中Control和模型中一部分挖了出来,以角色场景方式进行重新组合。这是一种与MVC模式考虑角度完全不一样的新角度,这种角度更符合OO。

最近,有人提出 场景Context是新的对象类型,场景不但可以替代SOA的Web服务,也可以替代MVC的控制器。

个人认为:未来新的分层架构可能变成这样:
View --> Context ---> Domain Model ---> Component/Respository

MVC模式已死。

[该贴被admin于2010-04-09 14:22修改过]

101
bigmouthz
2010-04-09 13:38

这个问题的分析可以从股票软件中就可以看出MVC的严重不足,
动态对象间的交互已经不是单纯的页面与事件的关系,而是跨页面

jsp/asp/这种瘦客户端的技术已经不堪重负,满足不了这种场景,单纯引进一个ajax就是足够的复杂

因此未来的发展我认为胖客户端技术应该更有前景
它在解决MVC,AJAX所要解决的问题上有着先天的优势,并且克服了其不足

请大家拍砖

liujian1979
2010-04-09 13:56

最近在看Ruby on Rails ,感觉在ORM方面,简直完全没有关系型DB的影子了.但依然是MVC架构,看来它的命运也不乐观吗?

villagehead
2010-04-09 13:59

我感觉mvc最重要的好处是在开发较大项目中,
可以让流程中各个模块各司其职。

至于
A、“很多人在Struts的Action控制器中写业务代码”,
只能归咎于2点。
1、写代码的人“修炼”不够。不能理解高内聚低耦合的OO思想主旨
2、项目负责人放任自流。导致代码混乱。

B、“控制器变得依赖信息数据中心或数据库”
现在的MVC应该大概都再用spring这样的IOC容器再对控制器进行分层,诸如service层dao层之类,
说“依赖”,也是应该service和dao之间的依赖。
而且这种依赖是和需求相关的,也就是和业务逻辑相关的,
个人感觉也是一种“合理的存在”

C、“对象将间接地通过控制器的action耦合在一起”
这个“缺点”到很客观。
不过,作为开发整个项目的人来说,
“构架师制定框架,程序员去实现业务逻辑“是“完美的结构”。
DDD对于中小项目可能更有“效率”,
但是对于大项目而言,
可能会让构架师和程序员的工作分工不明确。
构架师过多的考虑业务细节;而程序员则会接触更多,不属于自己的“细节”
这样可能会增加开发成本和带来更多的bug

而“对象和action耦合在一起”,也基本符合具体业务流程设计的思考方式
(就像一串糖葫芦,山楂的就串山楂,山药蛋的就串山药蛋)
(更不能指望需求定制和需求分析人员考虑构架/代码方面的内容)
(没有贬义,的确也不应该他们去考虑这方面的内容)

D、“重要的事情都集中在控制器中”
和B的观点一样,使用spring可以更好的“细化”责任、更好的执行“开闭原则”
好吧,既然是“only interesting”,那就让它“interesting”吧
但不要“only”

这是我对作者4点的一点个人见解,
也许是被MVC“奴役”惯了,
导致思维模式僵化,说话也比较极端。呵呵

当然作为一种技术领域新的概念,
无论有任何发展都是好的。

但是存在就是有价值,
“已死”之类的词还是有点“牵强”,
(也许有一点点点点“哗众取宠”的意思)

servlet出现的时候,perl/php已死
jsp出现的时候,servlet已死
struts2出来的时候,struts1已死

用郭德纲说过的一句话形容
“现在‘黄鹤楼’、‘报菜名’还能让观众笑的前仰后合的...”,呵呵

我经验不多,欢迎大家指正

个人观点,欢迎拍砖

good luck

javagens
2010-04-09 14:11

同意,DCI更符合业务逻辑。
我想知道DCI在JAVA领域除了JF,还有什么好的框架吗?
[该贴被javagens于2010-04-09 14:15修改过]

9Go 1 2 3 4 ... 9 下一页