Are the roles of a service and a façade similar?

The more I read, the more confused I am.

Note that all the question is related to how service and facades fit on the MVC pattern.

My understanding is that a Facade is not a super-smart object, it is simply a way of exposing a simple interface/api to perform a complex operation (example: perform a 10$ payment, it is a complex operation that involves a number of operations, but such complexity can be handled by a facade which will just call the corresponding object in a particular order...etc...)

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 it is what I understand so far).

Question then is, what is the difference between a facade and a service? At the end of the day, 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.

Same happens with transactions, I understand that a service is the place to start transactions, but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.

So which stack would make more sense

controller-facade-dao controller-service-dao

or maybe

controller-facadade-dao AND sometimes controller-facade-service-dao ??

Solution 1:

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

1. The DAO is a kind of service to the database, but really the DAO is a design pattern itself.
2. If you write your own DAO, you should never need a facade.

Therefore the correct answer is:

• controller - dao

Solution 2:

Literally, Facade as the name suggests means the front face of the building. The people walking past the road can only see the facade, They do not know anything about what inside it, wiring, the pipes and other complexities. The face hides all the complexities of the building and displays a simpler friendly face.

In software terms, facade hides the complexities of software components behind it by providing a simpler interface, doesn't have the functionality of its own and doesn't restrict the access to the substsyem. Commonly used in Object Oriented Design. Good examples are SLF4J - It is an api which is a simple facade for logging systems allowing the end-user to plug-in the desired logging system at deployment time.

A service is a public interface that provides access to a unit of functionality and always written to a specification. It needs to support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require. There is process services - encapsulation of business workflows , business logic service - encapsulation of rules/functions, data services - interaction with entities, data access management, infrastructure services- utility functions such as monitoring, logging & security. Services are mostly reusable, unassociated, loosely coupled units of functionality.

They are lot similar but depends on how you look at it.

The difference that I see, Facades are designed inside out. You look at subsystem and design a facade to provide simpler access. Services are designed outside in. You look at your customer/clients define a contract and design the service.