design-patterns - 还有哪些类似 MVC 的设计模式/架构可用于高度灵活的应用程序？

Question

前阵子我在某处读到有关如何改进 MVC 模式以适应我们今天看到的高度灵活和分层的 (web) 应用程序。 (令我沮丧的是，我似乎再也找不到那篇文章了)

例如，某些 Google 应用程序(如 GMail)甚至浏览器(如 Firefox)。

它由可以扩展和完全替换的组件组成。用户可以选择他们喜欢的用户界面或主题，有某种插件系统等等......

好吧，我知道，这就是构建大型/优秀应用程序的方式。这就是我问这个问题的原因。

您能否为我提供有关使用哪些模式或这些应用程序如何在架构上构建的资源或见解...

Answer 1

我猜你是在谈论软件架构(相对于硬件或系统架构)。

可能最重要的规则(我不会称之为模式)是关注点分离。这意味着一个组件应该只处理一个任务，只有那个任务和完整的任务。如果你坚持这样做(这比看起来更难)。您将拥有您提到的可插拔性的基础，例如交换用户界面。如果你的 UI 层真的只做 UI，它可以被完全不同的东西代替。

如果你真的在说大话，就像提到的 GMail，“最终一致”的概念就变得很重要。经典应用程序的结构是用户执行一个 Action ，比如按下一个按钮。应用程序处理该操作(例如，将表单中的数据保存到数据库中)。并在完成后刷新 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 > architecture twitter <.