When to use Gateway design pattern
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.
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.