一句话，媳妇是别人的好！
MVC被大量使用，所以被找出一些并不那么合适的场景，但这并不代表MVC能被完全替代。
DCI一个新概念的提出，我们往往只看到她美好的一面，
但当她也像如今的MVC一样大量应用的话，同样会暴露出很多的缺点。

如果说DCI更加侧重于分析，将代码和需求分析无缝结合起来，那么事件驱动架构EDA对MVC的替代则是完全技术性质，而且已经再开始：

Node.js也许是下一个革命

如果你在做一个小系统，MVC就可以了，但是如果你要做一个将来可能扩展到大系统，那么就要用事件驱动。习惯MVC思维的人会不习惯事件驱动。这又是一场淘汰革命。

开始学习使用Node.js

场景的概念大概就是GTD(时间管理)中的场景概念吧！

一个人有很多Method，比如吃饭、洗澡，但在特定场景下你才能执行这些Method,比如浴室才能洗澡，不能在客厅洗。

笔者从事过MVC的设计和生产工作吗?
从传统的工业设计,到现代化的航天航空领域,那一项没有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修改过]

大部分很有道理.至少我遇到的情况就是这样. 架构师做好架构很重要. 如果基础不踏实,就像一个摇摇欲坠的塔,还在它身上加建各个小塔,只能死得更快.

我认为，可能很多时候我们会把一个东西到处乱套， MVC是一种思想， 并且我认为可以用的范围要靠你自己的理解了，有可能V里面再细分还是MVC，所以，如果从一个大大框里面仅套用了这个格式，才会controller里面写上所有的control代码，这个我觉得是自己层次不清晰，而不是MVC限制了层次。 面向过程，面向对象都一样，应该相辅相成，面向对象的代码里面不用一句过程代码行么？ 能完成一个程序么？ DDD这样的模式也都一样，理解前不要硬套，也不要一上MVC就会跟data object， sql撤上关系，我单片机里面编程一样可以MVC。 思想总归是思想，当然，也不会死了，或者以后都是DDD大行天下了。

没有最好，只有最合适的。
不管你什么语言、什么框架、什么架构啊，聪明的人选择合适自己的，傻傻的人选择大家说最牛的

在action里代码多有什么问题吗？

我的看法，不在于哪里代码多、负责，哪里代码少，过于简单，而问题在于哪里应该多，哪里应该少。这不是任何框架和模式的问题，而是设计过程中没有好的架构师，没有好的架构。

不好好做架构，使用任何先进的模式、任何先进的框架都作用不大的。因为你自己的问题，只有自己去面对，去解决。不要指望别人解决你的问题。

如果有头脑清楚的架构师，做了清晰的复杂度切分、系统架构，甚至可以不使用任何能叫出名字的模式（什么MVC都歇菜吧），什么叫出名字的框架，都可以顺畅高效的开发；当然，有好用的模式和框架也如虎生翼。

任何系统都是MVC模式的

系统A调用了系统B的服务，那么：
系统A是V，中间的接口就是C，系统B是M

例如：
浏览器是V，服务端是C，数据库是M

而你说的action都上千行了，这种问题当然是有的。但并不是不用MVC就可以避免的