前段时间我在某处了解了如何改进MVC模式以适应我们今天看到的高度灵活和分层（Web）应用程序。 （令我沮丧的是，我似乎无法再找到那篇文章）
例如，一些谷歌应用程序，如GMail，甚至像Firefox这样的浏览器。
它由可以扩展和完全替换的组件组成。用户可以选择他们喜欢的用户界面或主题，有某种插件系统等等......
Owkay我知道，这就是构建多大/大的应用程序。这就是我问这个问题的原因。
您能否向我提供有关使用何种模式或如何在架构上构建这些应用程序的资源或见解......
答案 0 :(得分：5)
我猜你在谈论软件架构（与硬件或系统架构相反）。
可能最重要的规则（我不称之为模式）是关注点。这意味着一个组件应该只处理一个任务，只处理该任务和完成任务。如果你坚持（这比它看起来更难）。您将拥有所提到的可插拔性的基础，例如：交换用户界面。如果您的UI图层确实只有UI，则可以用完全不同的东西替换它。
如果你真的说话很大，就像上面提到的GMail一样，'最终一致'的概念变得很重要。经典应用程序以用户执行动作的方式构造，例如按下按钮。应用程序处理该操作（例如，从数据库中的表单保存数据）。并在完成后刷新GUI（例如，用编辑按钮替换'保存'按钮。这种线性处理有益处，用户总能看到一致的状态。如果他转身搜索数据库，他会找到他的但是当你在系统上负载极高时，这并不能很好地扩展，因为保存的最佳数据库在大多数情况下并不是完美的搜索数据库。所以有些应用程序会这样做：当用户点击保存按钮时，以可能的方式存储数据（例如，为更新而优化的数据库），设置需要进一步处理的标记并刷新gui。现在有一个单独的过程来处理保存的数据例如，通过更新特殊索引或将其存储在为搜索而优化的单独数据库中。第二个过程可能会收集许多操作的更改，以提高性能。
使用此设计，您可以进一步扩展，因为您正在分离关注点：存储和搜索数据是两个不同的任务，因此它们被拆分为两个不同的组件，这可以在这个极端情况下并行工作。对于用户而言，这意味着他可能不会立即找到他刚刚保存的东西，但他最终会找到。因此'最终的一致性'
编辑：我忘记了资源。关于应用程序架构的好书是：Martin Fowlers的企业应用程序架构模式。对于一般的模式当然是：关于消息传递体系结构'http://www.amazon.de/s/ref=nb_ss_eb?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Denglish-books&field-keywords=Enterprise+Integration&x=0&y=0'的模式的'设计模式'。我不能推荐任何有关可扩展性的书籍，但我建议使用“构建可扩展的网站”。各种大型应用程序（例如Twitter）的体系结构是会话，演示文稿和论文的主题，因此当您使用google时，您将获得大量资源。建筑推特＆lt;。
答案 1 :(得分：2)
Model View Presenter（MVP），它经常与MVC混淆，但我觉得它更灵活，尽管它可能会受益于额外的控制器组件。我无法告诉你它是否在大规模应用程序中更有用，但它绝对是一个类似MVC的模式。存在其他MVC变体，例如Model View ViewModel（MVVM），但是这一变体更适用于Microsoft的WPF。
答案 2 :(得分：-1)
查看Martin Fowler catalog是否有帮助