Spring and Hibernate transactions

I am new to Spring and I was just reading the docs about Hibernate-Spring integration (version 3). I don't get why the automatic transaction management (the declarative one) is applied to a "service" in the docs, instead to the DAO implementation directly. In particular I don't get what do they mean by service, what's the difference compared to a DAO and if this is really needed to provide Hibernate integration with Spring.

What I tried to do was to use just a Hib开发者_运维问答ernate DAO Implementation and configure in XML to have the session factory set upon instantiation. Anyway, that throws exceptions, because Spring doesn't allow for non transactional hibernate access. So in order to add transactional access, do I have to add that "service" thing? How has that to be different from the simple DAO?

I cannot say for Spring, but I'll answer this question in a generic way:

In particular I don't get what do they mean by service, what's the difference compared to a DAO

Imagine the classical "money transfer" scenario, where one customer sends money to a second customer. There is one "service" here (money transfer), which is done in two steps: deduct money from account A, add money to account B. Those two steps should be in one transaction, even though each of them does a database manipulation. If the transaction fails during the second step, the first should also be cancelled.

In this case, the Service would look like this:

transfer(Account to, Account from, double value)

And the DAO would look like this:

updateBalance(Account account, double amount)

The transfer method would call updateBalance twice, one for each operation.

I'm not very familiar with Spring these days, so, I'm not sure if (and why) Spring would require your application to have an extra layer if your business needs doesn't requires so.

DAO (Data Access Object) is only a design pattern or the name of the class that implment this pattern.

Service is a (Spring) term for an (most singleton like) class that provides some (business) service functionality. And it is also the name of an Annotation to declare an class as a service in Spring.

corrected: Repository instead of Resource

In spring there are many ways to implment a DAO, the most two commons are:

• Using the Spring Hibernate Template Class (Is deprecated in Spring 3.0)
• Doing it by Hand, and mark the DAO class by @Repository annotation (That is similar to @Service, (because @Repository and @Service are only meaning providing subclasses of @Component))

The DAO's responsibility is to encapsulate data access against a database. Examples of data access in a database are save, add, delete, get. Notice it has nothing to do with any business logic.

The Service's responsibility is to orchestrate the business logic. For example, your user has submitted two items. You don't automatically save them to the database. You might want validate first if the items are valid. You might want to filter or enrich the data associated with these items as well. Once you're done with validation and filtering/enriching then that would be the time you save it to do the database. To save your items, you use the DAO.

You can apply transactional semantics both to services and to DAOs. Normally you would want them applied at least to services because your service methods will sometimes involve calls to multiple DAOs that need to be part of the same transaction. (Great if you can get everything to happen in the SQL, but can't always do it.)

If you want to call DAOs directly from a controller (which happens sometimes in the context of a domain-driven design, or even in tiered designs where you simply prefer to call DAOs directly instead of implementing pass-through service-tier methods), you'll need transactions on your DTOs.

Transactional services and DAOs can work just fine together as long as the transaction propagation on the DAO is appropriately set. I.e. use an existing transaction where one exists but create a new one if there isn't one.