MVC被大量使用，所以被找出一些并不那么合适的场景，但这并不代表MVC能被完全替代。
DCI一个新概念的提出，我们往往只看到她美好的一面，
但当她也像如今的MVC一样大量应用的话，同样会暴露出很多的缺点。
MVC被大量使用，所以被找出一些并不那么合适的场景，但这并不代表MVC能被完全替代。
DCI一个新概念的提出，我们往往只看到她美好的一面，
但当她也像如今的MVC一样大量应用的话，同样会暴露出很多的缺点。
如果你在做一个小系统，MVC就可以了，但是如果你要做一个将来可能扩展到大系统，那么就要用事件驱动。习惯MVC思维的人会不习惯事件驱动。这又是一场淘汰革命。
一个人有很多Method，比如吃饭、洗澡，但在特定场景下你才能执行这些Method,比如浴室才能洗澡，不能在客厅洗。
从传统的工业设计,到现代化的航天航空领域,那一项没有MVC的身影?
从身边的:汽车
到太空的:哈勃望远镜
只看看这2个产品,你就可以在上面找到数不清的MVC的设计思想
说到软件生产领域,我看笔者都没弄清MVC职责划分的逻辑,
我给说说其中的一种方案吧:
M:领域相关的业务模型,一种业务类型对应一个M,他们可以重复使用在不同的项目中,他们只关注行为,数据无关
C:领域无关,项目无关,数据无关,平台相关的视图驱动器,
也就是说每一种平台的UI对应一个专用的驱动器,
在一种UI平台下,比如说:html只需要一个驱动器驱动,一个驱动器渲染所有的UI
V:领域相关的业务外观模型,一种业务类型对应一个V,他们可以重复使用在不同的项目,只描述外观,数据无关
一种UI平台对应一组View,而一个View可以映射对个UI;
可以看出,MVC有各自的接口,有不同平台的实现,你可以任意组合搭配或替换他们
单个系统谈不上架构. 一个用户自从来到登录页面,经过权限过滤后,就仿佛进入一个菜市场,里面的活动错综复杂,或者乱七8糟. 程序员面对的就是是业务,技术???.也用不了什么技术.
关键是有没有人能不能把一条条的业务用清晰的流程来完成它.
sorry,目前公司真的留不住我了.感觉在项目上,程序员集中交流欠少,很多很cool的想法,或者技术得不到分享...
所以13年,好好看书,多和大牛交流,拥有程序员自己的圈子.
这mvc嘛,我感觉像人. 刀在手上划了一下,感觉到疼. 首先是,手接受到外物的伤害,传递了一个事件,然后大脑捕捉到,再引导做出其它活动...
[该贴被zhhaojie于2013-01-06 18:30修改过]
2010-04-09 13:59 "@villagehead"的内容
我感觉mvc最重要的好处是在开发较大项目中，
可以让流程中各个模块各司其职。
可以让流程中各个模块各司其职。
至于
A、“很多人在Struts的Action控制器中写业务代码”，
只能归咎于2点。
1、写代码的人“修炼”不够。不能理解高内聚低耦合的OO思想主旨
2、项目 ...
大部分很有道理.至少我遇到的情况就是这样. 架构师做好架构很重要. 如果基础不踏实,就像一个摇摇欲坠的塔,还在它身上加建各个小塔,只能死得更快.
不管你什么语言、什么框架、什么架构啊，聪明的人选择合适自己的，傻傻的人选择大家说最牛的
我的看法，不在于哪里代码多、负责，哪里代码少，过于简单，而问题在于哪里应该多，哪里应该少。这不是任何框架和模式的问题，而是设计过程中没有好的架构师，没有好的架构。
不好好做架构，使用任何先进的模式、任何先进的框架都作用不大的。因为你自己的问题，只有自己去面对，去解决。不要指望别人解决你的问题。
如果有头脑清楚的架构师，做了清晰的复杂度切分、系统架构，甚至可以不使用任何能叫出名字的模式（什么MVC都歇菜吧），什么叫出名字的框架，都可以顺畅高效的开发；当然，有好用的模式和框架也如虎生翼。
系统A调用了系统B的服务，那么：
系统A是V，中间的接口就是C，系统B是M
例如：
浏览器是V，服务端是C，数据库是M
而你说的action都上千行了，这种问题当然是有的。但并不是不用MVC就可以避免的