技术架构：服务层还是没有？

Question

we have a platform composed of few applications.

We have to develop an API which must factorize all interaction to a database. In this API, we will too have a version of the database in XML format. The XML format will be used just by one application.

Our application are developped in a classic architectural : dao - service layer - presentation layer.

The DAO layer will be moved into API. No problem on that point. In many application, the service layer is just a gateway between presentation & dao layer without specific business code.

So my questions are :

• should we create the API with a Service layer for each dao ?
• if yes, so keep a service layer in application which call service layer from API ?
• should we create a service layer in API which manage the factory (database/XML), but that mean each application has to give an information to choose the dao to select (when just one application has this need) ?
• or just create all dao in different packages for database & xml in API, keep factory in the application which has the need, and call dao (database) in all others ?

Need help ! :p I'm lost...

FYI, we are in Java 1.6 with Spring 3.1.1. JDBC Template in DAO for moment. We are looking informations about spring data jdbc to replace JDBC Template. Any suggestion about that can be appreciated ^^ [ No Hibernate - JPA solution ]

Thank you.

---

[edit 1]

In other word, keep a service layer in application & in the API is a way for me to have an abstraction layer. If we have to modify the database structure, maybe we don't have to edit all applications if we can make some changes directly in the service layer of API too.

Imagine 3 possibilities :

1. service layer in API with factory to choose which dao to use (xml/database)
2. just dao in API
3. service layer in API for database & specific layer in API for XML

What solution do you choose ?

[edit 2]

Is it interesting to create an unique class to call the API ? like in a Facade design Pattern.

Answer 1

Use the Service Layer for what is meant to do: provide real world services, by using one ore more DAOs per service offered (and other stuff like managing transactions, sanitizing String s and other things like that).

If you (together with a more experienced coworker) think you don't need this service layer, then do not put it into your architecture. But make sure to create a proof of concept of your architecture (this may contain the implementation of a somewhat complex functionality of the system or part of it) so you can evaluate it later to demonstrate if you really don't need such layer (or if you do).

Answer 2

My understanding is that you need to decouple and reuse the business layer from the presentation layer, having multiple client applications using the same business implementation.

In this case you need to implement the service layer in the API. Some advantages:

1. You don't need to repeat the service implementation for any client application handling the presentation.
2. You can easily decouple the database model design from the business. Design patterns (DTO, Facade) and cross cutting concerns may be easily introduced.
3. A well designed service layer will require a minimum amount of modifications, compared to DAOs holding DB implementation details.

In this API, we will too have a version of the database in XML format. The XML format will be used just by one application.

By providing this implementation via the API more client applications will be able to use it in the future, if needed.

Spring remoting is offering excellent tools for such a design (RMI, HTTP invoker etc)

I don't see any added value in proving an API for DAOs.