A service is a way of writing an interface to an external system, such as a LDAP identity store, a payment gateway or an application management interface. It’s a conceptual way of looking at the external system as a provider of useful services perhaps with internal behaviours rather than a passive lump to be operated upon.
A facade is a way of wrapping up anything (including a service) to present it nicely to another component. Facades are often used when:
- A library or component is complex and your application needs only a subset of it. Your Facade presents the simplified API to the application
- You are using several libraries or components and need to unify them, presenting a consolidated API to the application
- The library you are using has a complex setup or set of dependencies, and the facade wraps all that up in the context of your application.
The bit that is really confusing is that you can (and often do) create a facade over one or more services. The service is the way that the component actually accesses the resource, and the facade is the bit which simplifies the component (such as configuration of options, connecting, etc).
If you write your own DAO, you probably will create your service just how you need, so writing a facade is an indication you did it wrong. If the DAO is built by a third party, and is more complex than your needs, then you can facade the service.
Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but is is what I understand so far).
I would say that the DAO is a design pattern all its own – see wikipedia.
If we contrast a DAO with a service, we have:
- Level of API:
- DAO: Fine-grained access to properties
- Service: Coarse-grained access to services
- Where implementation lies:
- DAO: Mainly on the client, but storing data (without behavior) in the database
- Service: Mainly on the server
- How the interface is invoked
- DAO: The client directly binds to the object in the same namespace and JVM
- Service: The client is simply a stub for a network, cross-vm or cross-namespace operation
… the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.
A facade could wrap up the DAO layer, but I don’t really see this happening in a useful way. Most likely you need an API to access the individual properties of the objects, traverse the object graph and similar, and that is precisely what the DAO provides.
Same happens with transactions, I understand that a service is the place to start transactions …
Absolutely, because the transaction is a service provided by the database and on another component or system
… but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.
And in many ways the transaction manager service is a facade onto a much more complex backend implementation, co-ordinating the transaction on the web, application, database and other transaction-aware components. However this is already abstracted away by the transaction service implementation. As far as we, the user, are concerned, there is only the public interface.
This is, in fact, the conceptual point of these design patterns – to provide just the right amount of API to the user, abstracting the complexities of the implementation behind the iron wall of the component interface.
So which stack would make more sense
controller-facade-dao controller-service-dao
or maybe
controller-facadade-dao AND sometimes controller-facade-service-dao ??
- The DAO is a kind of service to the database, but really the DAO is a design pattern itself.
- If you write your own DAO, you should never need a facade.
Therefore the correct answer is:
- controller – dao