Why use service layer?

I looked at the example on

[To see links please register here]

I'm trying to figure out why the service layer is needed in the first place in the example he provides. If you took it out, then in your client, you could just do:

UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}

It seems like the service layer is simply a wrapper around the DAO. Can someone give me a case where things could get messy if the service layer were removed? I just don’t see the point in having the service layer to begin with.

Take a look at the following article:

[

[To see links please register here]

][1]

It all depends on where you want to put your logic - in your services or your domain objects.

The service layer approach is appropriate if you have a complex architecture and require different interfaces to your DAO's and data. It's also good to provide course grained methods for clients to call - which call out to multiple DAO's to get data.

However, in most cases what you want is a simple architecture so skip the service layer and look at a domain model approach. Domain Driven Design by Eric Evans and the InfoQ article here expand on this:

[

[To see links please register here]

][2]

[1]:

[To see links please register here]

[2]:

[To see links please register here]

Using service layer is a well accepted design pattern in the java community. Yes, you could straightaway use the dao implementation but what if you want to apply some business rules.

Say, you want to perform some checks before allowing a user to login into the system. Where would you put those logics? Also, service layer is the place for transaction demarcation.

It’s generally good to keep your dao layer clean and lean. I suggest you read the article [“Don’t repeat the DAO”][1]. If you follow the principles in that article, you won’t be writing any implementation for your daos.

Also, kindly notice that the scope of that blog post was to help beginners in Spring. Spring is so powerful, that you can bend it to suit your needs with powerful concepts like aop etc.

Regards,
James


[1]:

[To see links please register here]

Having the service layer be a wrapper around the DAO is a common anti-pattern. In the example you give it is certainly not very useful. Using a service layer means you get several benefits:

* you get to make a clear distinction between web type activity best done in the controller and generic business logic that is not web-related. You can test service-related business logic separately from controller logic.

* you get to specify transaction behavior so if you have calls to multiple data access objects you can specify that they occur within the same transaction. In your example there's an initial call to a dao followed by a loop, which could presumably contain more dao calls. Keeping those calls within one transaction means that the database does less work (it doesn't have to create a new transaction for every call to a Dao) but more importantly it means the data retrieved is going to be more consistent.

* you can nest services so that if one has different transactional behavior (requires its own transaction) you can enforce that.

* you can use the postCommit interceptor to do notification stuff like sending emails, so that doesn't junk up the controller.

Typically I have services that encompass use cases for a single type of user, each method on the service is a single action (work to be done in a single request-response cycle) that that user would be performing, and unlike your example there is typically more than a simple data access object call going on in there.