Service vs. DAO vs. transaction vs. design question

I am trying to figure out the exact role of services and how they are used in relationship to dao objects.
I have several dao objects (User, Group, Role), each dao object is accessed via a service.

I have one java application (as opposed to a webapp) that will access many of the services (e.g. GroupService, UserService, RoleService) in order to save users, groups, roles, etc as it processes data.

For example:
Group group = new Group();
...
getGroupService().saveGroup(group);
User user = new User();
...
getUserService().saveUser(user);

My question is that I am wondering if I should create a service that encapsulates the User, Group, Role service so that the Hibernate session is shared across them all the domain objects, or is my understanding wrong?

My basic understanding is that I should create a service that would wrapper any of the dao objects that I would want to participate within a single transaction. If I have a a use case scenario that only involves roles, I would have to have a RoleService just to handle roles, however, if I want to handle a use case that simitaneously changes roles and users, I would create a UserRoleService.

Is my understanding correct, or do I need to be spanked?
Thanks.

It depends on the size of your application - if you only have a handful of DAOs, it might make more sense to have a single service - rather than one per DAO. I tend to create them on a use-case basis, and break them up when my tests get too large.

Here's some blog posts (and comments) you might find interesting:

http://raibledesigns.com/page/rd?anc...rvice_class_or

http://www.theserverside.com/news/th...hread_id=23705

Hope this helps!

Eric Evans wrote a book about Domain Modelling.

It talks about the concept of an Aggregate Root. Essentially, this means when creating object models (more specifically, domain models) you'll find that these aggregate roots start to form. They are the boss objects that clients would typically go through to work with other objects.

Consider the classic PurchaseOrder and LineItem world....

In this case the PurchaseOrder forms a clear aggregate root as you would'nt want clients of your domain model to operate on lineitems directly. You'd want the client to tell the purchase order to add a line item.

If you follow what I'm saying....

I think if you're doing Domain Modelling then your business interfaces become more inline with the Aggregate Roots as Mr Evans describes.

In that case, I think it works out that you end up with a fairly one-to-one correspondence between business interfaces and dao interfaces. Over time this may shift to more business or more dao interfaces as requirements dictate.


Just a thought....

Joe

Hey friends.,

I want to know what is the difference between DAO & SERVICE classes..? ? ?


when we create a dynamic web project using Spring & hibernate.,
how the followings are act.? ? ?

1.controller
2.DAO & impl
3.service & impl

@priyanka_hdp:
This text should be helpful in understanding the respective tasks of DAOs, services and controllers:
http://carinae.net/2009/11/layered-a...-and-spring-3/

HTH
Fokko

thnkx dear friend.,
i'll go through that noteZ..