对于高度灵活的应用程序,还有哪些类似MVC的设计模式/架构?

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

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

如果你真的说得很大,像上面提到的Gmail,“最终一致性”的概念就变得很重要了。传统应用程序的结构是用户执行操作的方式,比如按下按钮。应用程序处理该操作(例如,从数据库中的表单保存数据)。并在完成后刷新GUI(例如,用编辑按钮替换“保存”按钮)。这种线性处理的好处是,用户总是能看到一致的状态。如果他转过身来搜索数据库,他就会在那里找到他的数据。但是,当您的系统负载非常高时,这并不能很好地进行扩展,因为用于保存的最佳数据库在大多数情况下都不是理想的搜索数据库。所以有些应用程序会这样做:当用户点击保存按钮时,以可能的最快方式存储数据(例如,为更新而优化的数据库),设置一个需要进一步处理的标记并刷新GUI。现在,一个单独的过程来处理保存的数据,例如通过更新特殊索引或将其存储在为搜索而优化的单独数据库中。第二个过程可能为许多操作收集更改,以提高性能。

通过这种设计,您可以进一步扩展,因为您正在分离关注点:存储和搜索数据是两个不同的任务,因此它们被分成两个不同的组件,在这种极端情况下,它们可以并行工作。对于用户来说,这意味着他可能不会立即找到他刚保存的东西,但他最终会找到。因此“最终一致性”

编辑:我忘记了资源。关于应用程序体系结构的伟大著作是:马丁·福勒的《企业应用程序体系结构模式》。当然,对于一般模式,“设计模式”是关于消息传递体系结构的模式。 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>架构Twitter<时,您将获得大量资源。

Model View Presenter (MVP),它经常与MVC混淆,但我发现它更灵活,尽管它可能从附加的控制器组件中受益。我不能告诉你它在大规模应用中是否更有益,但它绝对是一个类似MVC的模式。存在其他MVC变体,例如 Model View ViewModel (MVVM),但这一个更具体地说是微软的WPF。

看看是否 Martin Fowler catalog 帮助