敏捷强调快速迭代而不浪费计划。
MVC强调基于计划架构分离关注点。
由于非MVC技术需要较少的规划，它们是否更适合敏捷项目？
答案 0 :(得分：30)
在开始编码之前，无需考虑分离问题。而敏捷并不意味着您只需将代码写下来即可。敏捷意味着不要过于依赖于您对项目外观的初步认识，并且在需要时（如通常那样）准备重构，而不是害怕在此过程中抛出大量代码。
关注点分离可以使重构变得更加容易，因此MVC可以成为敏捷的大帮手。
答案 1 :(得分：3)
敏捷开发通常是快速原型设计和重构的过程。 MVC的关注点分离通常可以使这两个过程更容易，更快。
答案 2 :(得分：2)
设计模式是快速开发的基础部分。流行的设计模式很受欢迎，因为它们有广泛的用途严重依赖模式可以使项目的可行架构更快地结晶。设计模式提供的常用词汇使团队更容易沟通项目结构，并专注于特定领域的问题。如果一种模式对项目的进展不利，那么模式与其他替代方案之间的关系很可能被很好地理解，从而简化了重构到替代布局的任务。
话虽这么说，MVC模式具有巨大的引力。它运作良好的一个主要原因是它倾向于强调API。这种隔离使得更改系统的某些部分变得更加容易，而不会对不相关的部分产生重大影响。如果系统的某个层有缺陷，通常很容易改变该层而不影响其他层，因为它们由定义良好的API分隔。如果API本身存在缺陷，那么通常可以在不影响任一层的实际逻辑的情况下改变暴露的API（虽然这往往比第一种缺陷更难）。
答案 3 :(得分：1)
当你在结构和灵活性之间找到适当的平衡时，它的价值在于黄金。
我倾向于不喜欢大多数（当前的）MVC范例，因为我相信它们会引入无意义的抽象，重新发明轮子，并增加很多刚性。
但我也倾向于使用高度结构化的程序将内容从业务逻辑与数据访问分开，并且尽可能少地使用“配置”来完成一件事。理想情况下，要完成一件事，你只需编辑1-2件事。
不必要的抽象是许多问题的根源。
答案 4 :(得分：1)
敏捷中的关键词是“最简单的可能有用的东西”。
如果解决问题的最简单方法是：
然后那些将没有MVC，并将成为适当的敏捷解决方案。
如果从项目一开始就明白这样的事情就不会接近解决问题，那么在尝试下一个最简单的解决方案之前尝试它们并等待失败将是毫无意义的文字过程。< / p>