When to use Gateway design pattern

Question

while trying to get my head into some design patterns I've run across a sample that confuses me - hopefully it something easy to explain, and I'm just missing it.

my question is "where" does gateway fit into this? it seems redundant, as an added data access point.

the sample code has three classes -

1. person - which has getter and setter methods for each of the objects attributes
2. personDAO - which has data calls to do the CRUD.
3. personGateway - which has getAll and getCount - which are data calls too...???

I totally get making a DAO call for data, and the DAO uses the "person" class to create an object to pass back - but WHY NOT put the getAll and getCount in the DAO???

What LOGICAL position does the "gateway" play in this game?

--- added after reading responses ---

Ok - I apparently missed this while searching - and it does "help" clarify - Need some clarification with Patterns (DAO x Gateway) - HOWEVER, it seem very java centric and it actually skips the distinction I was hoping for -

I guess the answer is that DAO returns an "object" and an "object" is a single entity...not a collection. If you're retuning a collection (and it's debatable if you "should") then you'd use the gateway... but under no circumstance should you muddy the DAO with collections...

Answer 1

Gateway Pattern

A gateway encapsulates the semantic gap between the object-oriented domain layer and the relation-oriented persistence layer.

Definition taken from here.

The Gateway in your example is also called a "Service". The service layer is important because it provides a higher abstraction and a more "holistic" way in dealing with a Person entity.

The reason for this "extra" layer is the other objects in the system that are connected to a Person. For example, say there are Car objects and each Person may have a Car. Now, when we sell a car we should update the "owner" field, further you'll want to do the same for the Person objects that are involved (seller/buyer).

In order to achieve this "cascading" in an OO manner (without coupling the objects implementations) BuyCarService will update the new owners: the service will call CarDAO and PersonDAO in order to update the relevant fields in the DB so that the DAOs won't have to "know" each other and hence decouple the implementations.

Hope this makes things clearer.

Answer 2

Most of the Design patterns explanations become confusing at some time or other because originally it was named and explained by someone but in due course of time several other similar patterns come into existence which have similar usage and explanation but very little difference. This subtle difference then becomes a source of debates:-). Concerning Gateway pattern, here is what is Martin Fowler mentions in Catalogs of Enterprise Application architecture.I am straight quoting from here

"Gateway - An object that encapsulates access to an external system or resource."

Interesting software rarely lives in isolation. Even the purest object-oriented system often has to deal with things that aren't objects, such as relational data-base tables, CICS transactions, and XML data structures.

When accessing external resources like this, you'll usually get APIs for them. However, these APIs are naturally going to be somewhat complicated because they take the nature of the resource into account. Anyone who needs to under-stand a resource needs to understand its API - whether JDBC and SQL for rela-tional databases or W3C or JDOM for XML. Not only does this make the software harder to understand, it also makes it much harder to change should you shift some data from a relational database to an XML message at some point in the future.

The answer is so common that it's hardly worth stating. Wrap all the special API code into a class whose interface looks like a regular object. Other objects access the resource through this Gateway, which translates the simple method calls into the appropriate specialized API.