Web/企业应用程序中最常使用哪些设计模式？ [关闭]答案

【问题标题】：What Design Patterns are mostly used in Web/Enterprise Applications? [closed]Web/企业应用程序中最常使用哪些设计模式？ [关闭]
【发布时间】：2011-01-03 08:26:54
【问题描述】：

Web/企业应用程序中最常用的一些设计模式是什么？为什么要使用它们？

注意：回答为什么部分应该基于列出他们倾向于解决的问题？

【问题讨论】：

我认为这是一个过于宽泛的问题，有人无法编制一份清单。您最好选择一些特定的、知名的应用程序和门户，并专门研究/询问它们。
哇，这是一个很大的问题，我很想看答案
我正在寻找这个问题的通用答案，以便了解 Web/企业应用程序中常用的设计模式以及为什么使用它们，旨在了解它们倾向于解决的问题。
我推荐阅读 Martin Fowler 的企业应用架构模式martinfowler.com/books.html#eaa
这个问题是关于一般模式还是具体设计模式？

标签： design-patterns web-applications enterprise

【解决方案1】：

我经常使用Inversion of Control。

特别是在持久化/加载对象时。当我们不确定数据是来自数据库、Web 服务还是其他机制时，它会有所帮助。

通过使用一个接口并允许多个源公开一个简单的 API 用于保存/检索，并允许对象本身知道哪些 API 调用，从而使我们最终得到一个非常易于管理的架构。

here 就是一个例子。

【讨论】：

@Chris：你能解释一下你写在第 3 段中的想法吗，详细描述这种设计模式的工作原理
依赖注入是更具体、更常用的 IOC 形式。
我自己更喜欢使用依赖注入，而不是尽可能使用单例模式。
依赖注入，结合 Google Guice 等框架，也可以帮助摆脱单例——例如，使用 zombat 的示例，而不是拥有 DatabaseManager 单例，您可以确保 Guice 始终注入相同的 DatabaseManager 实例（或者，如果您不想使用 Guice，请始终在顶级代码中使用相同的 DatabaseManager）

【解决方案2】：

Singleton pattern 非常常见。它的主要用途是确保您从不实例化多个给定类型的对象，这使其成为全局变量的一个很好的替代品，后者具有明显的邪恶声誉。支持和反对 Singleton 有不同程度的争论，有些人声称它与全局变量一样糟糕。

我倾向于自己使用它来处理我通常称之为“经理”的广泛对象。例如，在需要多个数据库的大型应用程序中，您不希望一直打开很多连接。我将有一个 DatabaseManager 类，它是一个 Singleton，它将在内部管理与每个数据库的连接。消费对象可以调用DatabaseManager::getConnection() 方法，并且管理器的工作是确保存在单个连接（如果必须打开它），并将其返回给消费对象。

这解决了在整个地方传递全局数据库连接的问题，并具有高效对象使用的附带好处，因为只有一个 DatabaseManager 存在。静态调用意味着它可供任何需要它的消费者使用。

【讨论】：

+1 用于制定该问题的答案类型指南。感谢您的输入。非常翔实的答案。
单例只是另一个名称的全局。它仍然存在同样的问题。
单例并不总是最好的选择，而且通常被认为是有害的——更难测试、更难重构、额外的样板代码等。Steve Yegge 在这里有一篇特别尖锐的文章：@ 987654322@
于是辩论开始了！ :D @Kaleb - 那篇文章在修辞上很长，在例子上很短。如果你的 Singleton 类除了有一个单一的静态方法之外什么都不做，那么是的，你只是在使用一个美化的全局。但是，如果您有一个实际上涉及重要逻辑的类，可以在提供简单的外部接口的同时进行内部管理，那么 Singleton 就更有意义了。

【解决方案3】：

MVC

Model-View-Controller 允许业务逻辑和表示层之间的低内聚，这是它的主要价值。

通常每个控制器都是一个Servlet，它处理单个页面的 GET/POST 请求，通过呈现正确的视图或将管辖权转移给另一个控制器来响应它们。

Viwer 将 Controller 传递的数据转换为 Html、Xml、JavaScript、JSON 或任何您喜欢的技术。 Viewer 通常是 Servlet 或 JSP、ASP 等 Servlet 抽象。

模型是应用程序对其进行操作的数据的特定领域表示。它还可以与为数据提供意义的域逻辑相结合（例如计算生日、总计或购物车购物项目的运费）。模型应该封装数据，无论底层存储设施如何，都可以轻松访问。

由于它与 MVC 的低内聚性，您可以独立更改、开发和测试每个组件。

ActiveRecord

当底层存储机制是数据库时，经常使用这个。基本上，ActiveRecord 的意思是您的所有对象属性都对应于底层数据库中的列，并且每个对象都包含诸如插入、更新、删除（和加载）之类的功能。

所以每个类都被翻译成一个表或一个视图，每个对象成为所述表中的一行。

这样做的原因很简单，因为您的类实现了访问和编辑数据库的方法，您不必编写额外的样板代码。再加上数据库的流行，足以让这种模式保持有趣。

Pools

另一个经常使用的是Pools。 PoolManager 是一个管理Resource 的Singleton（无论是数据库、工厂方法还是连接）。 PoolManager 保存一组初始化的副本。每当另一个进程或对象通过PoolManager.acquire() 请求资源时，他都会从池中获取其中一个对象。
然后，他操作他的资源副本，并在完成后通过Resource.release() 将其返回。然而，对象并没有被销毁，它只是返回到池中。

Pools 用于提高性能。
例如，如果有一个工厂方法的检索成本很高（即响应速度很慢），它通常被包装在 PoolManager 中，并且在 PoolManager 的初始化时创建 N 个实例。这样客户就不会觉得底层工厂很慢，因为PoolManager 对他们造成了性能损失。

【讨论】：

【解决方案4】：

我认为 Facade 和 Adapter 模式被开发人员广泛使用，但他们不知道他们实际上是这样做的。

【讨论】：

您能否提供示例来解释使用 Facade 和 Adapter 设计模式处理的场景。

【解决方案5】：

一种常用的企业设计模式是Front Controller。它需要集中式接入点或入口点。由 J2EE 框架（如 struts、jersey 等）使用，因此开发人员可能不会注意到它。

【讨论】：

【解决方案6】：

模型视图控制器，用于将业务逻辑与表示层分离，以减少不必要的紧耦合。
在c2.com 或wikipedia 上查看更多信息

【讨论】：

【解决方案7】：

工厂模式，主要是 factory_object 和 factory_method 很常见，
例如用于 xml 文档的 DocumentFactory。
工厂模式的目的是简化对象的创建。

【讨论】：

【解决方案8】：

我不知道从哪里开始，因为你会发现到处都是模式（最终，在引擎盖下）。但是让我们尝试一下：

我猜大多数（全部？）MVC 框架都使用Front Controller 和Command [GoF] 模式。
在分布式应用程序中，使用基于Facade [GoF] 设计模式的Session Facade（用Java 中的Session Beans 实现）非常普遍。
ORM 实现 Unit Of Work [PoEAA] 模式（Java 世界中 Hibernate 的 Session、Toplink 的 UnitOfWork、JDO 的 PersistenceManager）。
对于数据访问层使用数据访问对象模式仍然非常频繁。 Abstract Factory [GoF] 和 Factory Method [GoF] 是相关的模式。
等等等等

【讨论】：

【解决方案9】：

我发现这很有用：http://misko.hevery.com/code-reviewers-guide/ 这与您提出的问题无关，而是解决了上面列出的一些设计模式。我强烈推荐阅读 pdf 书！

希望有帮助

【讨论】：