What Design Patterns are mostly used in Web/Enterprise Applications? [closed]

Question

What are some of the most common Design Patterns that are used in Web/Enterprise Application and why they are used ?

Note: Answer to why part should be based upon listing the problems which they tend to solve ?

Answer 1

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.

Answer 2

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.

Answer 3

I think Facade & Adapter pattern are widely used by developpers but they don't know they actually do.

Answer 4

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 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.

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. 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.