In particular, when persisting / loading objects. It helps when we're not sure if the data is going to come from a database, a web service, or some other mechanism.
By using an interface and allowing multiple sources to expose a simple API for save / retrieving and allowing the object itself to know which API calls to make we end up with a very easy to manage architecture.
The Singleton pattern is extremely common. It's primary use is to make sure you never instantiate more than a single object of a given type, which makes it a nice replacement for global variables, which have a decidedly evil reputation. There are varying degrees of arguments for and against the Singleton, with some people claiming that it is just as bad as global variables.
I tend to use it myself with a broad group of objects I generally call "Managers". For instance, in a large application that requires several databases, you don't want to be opening a lot of connections all the time. I will have a DatabaseManager class that is a Singleton, and it will internally manage connections to each database. A consuming object can call upon a DatabaseManager::getConnection() method, and it's the manager's job to ensure a single connection exists (opening it if it has to), and return it to the consuming object.
This solves the problem of passing around a global database connection all over the place, with the side benefit of efficient object use, as only one DatabaseManager is ever in existence. Static calls means that it is available to any consumer that needs it.
Model-View-Controller allows for low cohesion between business logic and presentation layer and this is its primary value.
Usually each Controller is a Servlet that handles GET/POST requests for a single page, responding to them by presenting a correct view or transferring jurisdiction to another Controller.
Viwer turns data the Controller passes, into Html, Xml, JavaScript, JSON or whatever technology you'd like. Viewer is most often a Servlet or a Servlet abstraction like JSP, ASP, etc.
Model is the domain-specific representation of the data upon which the application operates. It can also be coupled with domain logic that provides meaning to data (like calculating birthday, totals or shipping charges for cart shopping items). Model should encapsulate the data allowing easy access no matter the underlying storage facilities.
Due to its low cohesion with MVC you can change, develop and test each component independently.
This one is often used when underlying storage mechanism is a database. Basically what ActiveRecord means is that all your object properties correspond to columns in the underlying database and that each object includes functions such as Insert, Update, Delete (and Load).
So each class is translated into a table or a view and each object becomes a row in the said table.
The reason for this is simple by having your classes implement the way to access and edit the database you are spared of writing the extra boiler plate code. That coupled with popularity of databases is enough to keep this pattern interesting.
Another one often used is Pools. PoolManager is a Singleton that manages the Resource (be it database, Factory method or a connection). PoolManager keeps a set of initialized copies. Whenever another process or an object asks for resource via PoolManager.acquire() he gets one of the objects from a pool. He then manipulates his copy of the resource and returns it when he is finished via Resource.release(). The object isn't destroyed however, it is merely returned to the pool.
Pools are used to increase performance. For instance if there is a factory method that has a costly retrieval (i.e. it is slow to respond) it is often wrapped in a PoolManager and N instances are created on initialization of PoolManager. That way clients doesn't feel that that the underlying factory is slow since PoolManager takes the performance hit for them.
One of the commonly used Enterprise design pattern is Front Controller. It requires centralized access point or entry point. Used by J2EE frameworks like struts, jersey etc, so developers might not notice it.
工厂模式，主要是factory_object和factory_method很常见， 例如用于 xml 文档的 DocumentFactory。 工厂模式的目的是简化对象的创建。
Factory patterns, mostly factory_object and factory_method are very common, e.g. DocumentFactory for xml docs. The purpose of the factory pattern is to simplify object creation.
In distributed applications, it is/was very common to use the Session Facade (implemented with Session Beans in Java) which is based on the Facade [GoF] design pattern.
ORMs implement the Unit Of Work [PoEAA] pattern (Hibernate's Session, Toplink's UnitOfWork, JDO's PersistenceManager in the Java world).
It is still very frequent to use the Data Access Object pattern for the Data Access Layer. Abstract Factory [GoF] and the Factory Method [GoF] are related patterns.
I found this usefull: http://misko.hevery.com/code-reviewers-guide/ it's not about the question you ask but it address some of the design patterns listed above. I strongly recommend to read the pdf book!
发布评论
评论（9）
我经常使用控制反转。
特别是在持久/加载对象时。当我们不确定数据是否来自数据库、Web 服务或其他机制时，它会很有帮助。
通过使用接口并允许多个源公开用于保存/检索的简单 API，并允许对象本身知道要进行哪些 API 调用，我们最终得到了一个非常易于管理的架构。
此处就是一个例子。
I use Inversion of Control a lot.
In particular, when persisting / loading objects. It helps when we're not sure if the data is going to come from a database, a web service, or some other mechanism.
By using an interface and allowing multiple sources to expose a simple API for save / retrieving and allowing the object itself to know which API calls to make we end up with a very easy to manage architecture.
One example of this is here.
单例模式非常常见。它的主要用途是确保您永远不会实例化超过一个给定类型的单个对象，这使得它成为全局变量的一个很好的替代品，而全局变量有着明显的恶名。支持和反对 Singleton 有不同程度的争论，有些人声称它和全局变量一样糟糕。
我自己倾向于将它与通常称为“管理器”的广泛对象一起使用。例如，在需要多个数据库的大型应用程序中，您不希望始终打开大量连接。我将有一个单例的DatabaseManager 类，它将在内部管理与每个数据库的连接。消费对象可以调用
DatabaseManager::getConnection()方法，管理器的工作是确保单个连接存在（如果必须的话打开它），并将其返回给消费对象。这解决了在各处传递全局数据库连接的问题，并具有高效对象使用的副作用，因为只有一个 DatabaseManager 存在。静态调用意味着任何需要它的消费者都可以使用它。
The Singleton pattern is extremely common. It's primary use is to make sure you never instantiate more than a single object of a given type, which makes it a nice replacement for global variables, which have a decidedly evil reputation. There are varying degrees of arguments for and against the Singleton, with some people claiming that it is just as bad as global variables.
I tend to use it myself with a broad group of objects I generally call "Managers". For instance, in a large application that requires several databases, you don't want to be opening a lot of connections all the time. I will have a
DatabaseManagerclass that is a Singleton, and it will internally manage connections to each database. A consuming object can call upon aDatabaseManager::getConnection()method, and it's the manager's job to ensure a single connection exists (opening it if it has to), and return it to the consuming object.This solves the problem of passing around a global database connection all over the place, with the side benefit of efficient object use, as only one DatabaseManager is ever in existence. Static calls means that it is available to any consumer that needs it.
MVC
模型-视图-控制器允许业务逻辑和表示层之间的内聚力较低，这是其主要价值。
通常，每个控制器都是一个
Servlet，它处理单个页面的 GET/POST 请求，通过呈现正确的视图或将管辖权转移给另一个控制器来响应它们。Viwer 将控制器传递的数据转换为 Html、Xml、JavaScript、JSON 或您想要的任何技术。查看器通常是
Servlet或 Servlet 抽象，如 JSP、ASP 等。模型是应用程序操作所依据的数据的特定于域的表示。它还可以与为数据提供意义的域逻辑相结合（例如计算生日、购物车购物商品的总计或运费）。
模型应该封装数据，无论底层存储设施如何，都可以轻松访问。
由于它与 MVC 的内聚力较低，您可以独立更改、开发和测试每个组件。
ActiveRecord
当底层存储机制是数据库时，通常会使用此选项。基本上，ActiveRecord 的意思是，所有对象属性都对应于基础数据库中的列，并且每个对象都包含插入、更新、删除（和加载）等功能。
因此，每个类都被转换为一个表或视图，每个对象成为该表中的一行。
原因很简单，让您的类实现访问和编辑数据库的方法，您就不必编写额外的样板代码了。再加上数据库的流行就足以让这种模式变得有趣。
池
另一种经常使用的是池。
PoolManager是一个管理Resource的Singleton （无论是数据库、工厂方法还是连接）。 PoolManager 保留一组初始化的副本。每当另一个进程或对象通过
PoolManager.acquire()请求资源时，他就会从池中获取其中一个对象。然后，他操作该资源的副本，并在完成后通过
Resource.release()返回它。然而，该对象并没有被销毁，它只是返回到池中。池用于提高性能。例如，如果有一个工厂方法的检索成本很高（即响应速度很慢），那么它通常被包装在
PoolManager中，并且在初始化时创建 N 个实例。池管理器。这样，客户端就不会觉得底层工厂很慢，因为PoolManager为他们承担了性能损失。MVC
Model-View-Controller allows for low cohesion between business logic and presentation layer and this is its primary value.
Usually each Controller is a
Servletthat handles GET/POST requests for a single page, responding to them by presenting a correct view or transferring jurisdiction to another Controller.Viwer turns data the Controller passes, into Html, Xml, JavaScript, JSON or whatever technology you'd like. Viewer is most often a
Servletor a Servlet abstraction like JSP, ASP, etc.Model is the domain-specific representation of the data upon which the application operates. It can also be coupled with domain logic that provides meaning to data (like calculating birthday, totals or shipping charges for cart shopping items).
Model should encapsulate the data allowing easy access no matter the underlying storage facilities.
Due to its low cohesion with MVC you can change, develop and test each component independently.
ActiveRecord
This one is often used when underlying storage mechanism is a database. Basically what ActiveRecord means is that all your object properties correspond to columns in the underlying database and that each object includes functions such as Insert, Update, Delete (and Load).
So each class is translated into a table or a view and each object becomes a row in the said table.
The reason for this is simple by having your classes implement the way to access and edit the database you are spared of writing the extra boiler plate code. That coupled with popularity of databases is enough to keep this pattern interesting.
Pools
Another one often used is Pools.
PoolManageris a Singleton that manages theResource(be it database, Factory method or a connection). PoolManager keeps a set of initialized copies.Whenever another process or an object asks for resource via
PoolManager.acquire()he gets one of the objects from a pool.He then manipulates his copy of the resource and returns it when he is finished via
Resource.release(). The object isn't destroyed however, it is merely returned to the pool.Poolsare used to increase performance.For instance if there is a factory method that has a costly retrieval (i.e. it is slow to respond) it is often wrapped in a
PoolManagerand N instances are created on initialization ofPoolManager. That way clients doesn't feel that that the underlying factory is slow sincePoolManagertakes the performance hit for them.我认为 外观 & Adapter 模式被开发人员广泛使用，但他们并不知道自己实际上在使用。
I think Facade & Adapter pattern are widely used by developpers but they don't know they actually do.
常用的企业设计模式之一是前端控制器。它需要集中的访问点或入口点。由 struts、jersey 等 J2EE 框架使用，因此开发人员可能不会注意到它。
One of the commonly used Enterprise design pattern is Front Controller. It requires centralized access point or entry point. Used by J2EE frameworks like struts, jersey etc, so developers might not notice it.
模型视图控制器，用于将业务逻辑与表示层分离，以减少不必要的紧耦合。
有关更多信息，请参阅 c2.com 或 维基百科
Model View Controller, used to separate business logic from presentation layer to reduce unnecessary tight coupling.
See more on c2.com or wikipedia
工厂模式，主要是factory_object和factory_method很常见，
例如用于 xml 文档的 DocumentFactory。
工厂模式的目的是简化对象的创建。
Factory patterns, mostly factory_object and factory_method are very common,
e.g. DocumentFactory for xml docs.
The purpose of the factory pattern is to simplify object creation.
我不知道从哪里开始，因为你会发现模式无处不在（最终，在引擎盖下）。但让我们尝试一下：
UnitOfWork、Java 世界中 JDO 的PersistenceManager）。I don't know where to start as you'll find patterns everywhere (eventually, under the hood). But let's try:
Session, Toplink'sUnitOfWork, JDO'sPersistenceManagerin the Java world).我发现这很有用： http://misko.hevery.com/code-reviewers-guide/< /a>
这与您提出的问题无关，但它解决了上面列出的一些设计模式。我强烈推荐阅读pdf书！
希望这有帮助
I found this usefull: http://misko.hevery.com/code-reviewers-guide/
it's not about the question you ask but it address some of the design patterns listed above. I strongly recommend to read the pdf book!
Hope this help