DAO (data access object) best practices - examples I see use a DAO and a Services object both, what is the best practice here?

Question

I'm creating a data access object to retrieve information from Google App Engine for a web app built on the Spring framework (first time for all).

I see a number of examples that use a Controller/webapp -> Service -> DAO -> JDO/Google-app-engine pattern.

In this pattern the DAO layer is the only one that knows about JDO, thus this layer is the only one needing replacement if the data store changed. The Services layer calls the DAO layer and formats/manipulates the data s needed.

My question is why the extra Service layer? At least initially it doesn't seem like the Service layer is adding much to the equation. I would naturally think to just write a DAO layer to encapsulate the JDO requests and manipulate and return the data.

Can someone show me the rational for a separate Service layer, will this become obvious as the project becomes larges and more complex?

Answer 1

Typically you put DAOs in a service layer because as your app gets more complicated, you will do useful and non trivial things in the service. For example, you might coordinate complicated data operations with more than 1 DAO. Service layers also provide API boundaries that demarcate cross cutting concerns, like transaction management, authorization checks, performance logging, etc.

Another reason its good to abstract your functionality into services is that it promotes reusable and maintainable components. When you start, you might be interested in just presenting some html. You write a service that loads some data, and handle the html part in the layer above the service layer (presentation layer). Now you want to stand up a RESTful webservice. Your service layer can be reused to load the data; all you have to worry about is the json or xml your webservice endpoint returns (and of course the REST semantics).

So, for simple cases the Service layer might add little, but as your app expands they become worthwhile and even essential to keeping the code clean.

Answer 2

Yes, Initially it seems like the service layer does not adding much to the equation. But think about it like this.

Service Layer = a layer between your presentation and business layer.

You must have been aware that it is always good to have separation of concern between layers. Your service layer can map to distinct business domain, presentation layers, without being bothered of how your DOA layer is used.

You can think of this as boundary between two other layers, in this case between the presentation and business layers. The code in the presentation layer typically implements use cases. A typical use case is a sequence of actions performed by the user that result in interactions between one or more business objects, work flows, and services. The service layer allows you to abstract these smaller interactions with an intermediate API, exposed through more coarsely granular services. The presentation layer makes one call to one service in the layer. The invoked service layer method will coordinate the objects and work flows in the business layer to implement the required behavior.

Security Concerns

1. I do create a security layer around the Service stacks. This will helps me to identify the user authenticity and access the given service.
2. I do also have a transaction layer defined around the service layer, It tells the database engine to commit changes made in service layer, once it is returning after successful executions.

These things are also need to be in concern, if you are defining layers of your application.