这个问题意图与技术无关。您更喜欢哪种Web框架，以及何时：纯MVC或事件驱动的面向组件？
为了说明“技术不可知论”，我在这里用不同的技术/语言命名了一些MVC与组件Web框架：
答案 0 :(得分：5)
我白天是个开发者;但是，我更喜欢Wicket和/或Lift，尤其是后者。 Prado的问题似乎是控制器与页面绑定，而不是页面上的逻辑控件，否则，它似乎仍然比PHP领域的大多数其他选项更好。我认为所有这些都归结为可重用性，除非您拥有由控制器支持的组件，否则您无法将显示与支持控制逻辑完全分开。
所有这些'MVC'框架所暗示的MVC似乎很糟糕，你得到一个带有大量控件的逻辑页面，你必须处理页面控制器上的所有这些，哇，谢谢，现在我有MVC / n，其中n是控件的数量。到目前为止，我见过的大多数“MVC”系统都是脑死标签库的混合体，将请求响应扭曲到一个控制器中，该控制器必须知道页面上的所有内容。带有js的xhtml模板，和css奇妙地分开。除了支持这些组件的几个类之外，你突然想知道复杂的页面是如何工作的，或者如果你想要获取片段x，并将其放在其他地方。
答案 1 :(得分：2)
目前，'新热点'趋势是朝向MVC方式。我个人更喜欢MVC框架的惯例，因为许多占用宝贵开发时间的scut工作都被废除了。话虽如此，约束往往相当严格，在某些情况下可能需要更传统的基于组件的方法。总而言之，它是适合工作选择的正确工具。
答案 2 :(得分：2)
所使用的技术通常不是选择问题，特别是在大公司中，您没有太多选择。
如果我能够选择一种技术，我会选择Wicket。我一直在使用Spring MVC并且很好，但Wicket有一个简洁的功能，Spring MVC没有：服务器端状态管理和封装，丰富的组件模型，没有不必要的XML映射文件 - 只是纯Java和HTML。
答案 3 :(得分：1)
我主要是ASP.Net开发人员，但我发现MVC是创建功能复杂的网站（通常是业务线类型网站）的更好方法，因为它允许更好地将业务逻辑和规则与标记分离用于向最终用户显示数据。 对于快速和脏的站点（通常直接连接到数据库）或更丰富的接口，“事件驱动的面向组件的”模型更有效。
答案 4 :(得分：1)
就我个人而言，我会说MVC是去网站的方式。您可以更好地控制HTML和CSS，同时控制器模式可以很好地与HTTP协同工作。事件驱动的Web编程非常适合小型网站或那些没有使用HTML和CSS以及更多低级概念的人。
答案 5 :(得分：0)
我松散地遵循这些准则：
这个列表当然有很多空白，但这只是表示问题有多复杂。