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