How Common to Spring Manage Beans Created By Hibernate?

[diegum]

I have a question related to that SpringInterceptor

Let's suposse we have mapped 200 classes to tables but we need inject dependencies to about a 20% (40 of them)

Does SpringInterceptor enter on scene with every type of object Hibernate hidrate?

In other words, if a query returns 1000 object instances with all of them belonging to the remaining 80%, is SpringInterceptors going to be called 1000 times in vain?

If it is, there exists some workaround for such undesirable situation?

[sethladd]

There might be a way to first query the BeanFactory to see if it handles a particular class. That might be a quick lookup.

Or, if you know which classes you need to manage, you could configure that to the INterceptor, by checking a list of classes you want Spring to manage. That would at least bypass BeanFactory immediately with the added expense of a little more to configure.

[irbouho]

Let's suposse we have mapped 200 classes to tables but we need inject dependencies to about a 20% (40 of them)

You can specify the 20% using "persistantClassBeanNames" property.

Let's suposse we have mapped 200 classes to tables but we need inject dependencies to about a 20% (40 of them)

Does SpringInterceptor enter on scene with every type of object Hibernate hidrate?

Yes, this is how hibernate works, and this is a well know limitation for Hibernate Interceptors.

If it is, there exists some workaround for such undesirable situation?

even Hibernate3 new Listeners will be called for each event / object.

[irbouho]

There might be a way to first query the BeanFactory to see if it handles a particular class. That might be a quick lookup.

Or, if you know which classes you need to manage, you could configure that to the INterceptor, by checking a list of classes you want Spring to manage. That would at least bypass BeanFactory immediately with the added expense of a little more to configure.

This functionality is already implemented in SpringInterceptor. See my above post.

[diegum]

We have solved the problem of business object dependency injection after Hibernate loading

Our solution is not the best, it has PROS and CONS but we have tried to mitigate its CONS

I suggest you take a look and make your opinions

We have in our "domain" packages classes which model business objects

Some of them needs to be injected with behavior after being recovered from database records. Let's say com.company.domain.product.Product as an example

So, what we have done was subclass Product as an Hibernate specific class in a integration layer package

Thus, we have obtained com.company.integration.hibernate.product.ProductH ibernate

ProductHibernate implements an old (deprecated?) Hibernate interfase: Lifecycle with some methods of interest, in this case, onLoad(Session, ...)

In "Hibernate in Action", Bauer and King suggest not to use that interfase because implies adding Hibernate specific methods to a class which has only business methods

We realize that point but try to mitigate it by isolating Hibernate specific logic in a subclass in a strictly isolated hibernate package, warrantying the fact that in business layer no class will know that Product's are really ProductHibernate

If we have to change business logic, we change Product

Some PROS: we don't interfere Hibernate on every loaded class. Only in those classes we want to be interfered (really less than 5% of O/R mappings ocurred during execution)

Some limitation: what happen if tomorrow we need, in business layer, subclassing Product in ProductSpecial? Shall we need in such case to subclass again in ProductSpecialHibernate?

Really we now our solution has serious pitfalls but, with certain conditions, works fine

[Rod Johnson]

It would be good to quantify the performance cost of doing this. Anybody done a benchmark? (I would do it, but I don't have time at the moment.)

To support this usage I've slightly optimized prototype creation in Spring 1.1, and hope to dramatically reduce the overhead in common cases in Spring 1.2 by using clone() where possible.

[sethladd]

I am about to integrate the SpringInterceptor into our project. This is a dream come true, being able to implement business logic into our beans.

Would anyone know if this is something Spring will include in future releases?

Thanks!
Seth

[tufelix]

In Rod and Juergens book they have BusinessObjectManager and BusinessObject. We further refactored business strategies from business objects like BusinessStrategy.

Our BusinessObjectManager is wired up by dependency injection. It is injected with BusinessStrategy. BusinessObjectManager does not operate on BusinessStrategy but passes it by to BusinessObject.

Code snippet taken from BusinessObjectManager:

private BusinessStrategy businessStrategy;
private BusinessObjectDAO businessObjectDAO;
...
  BusinessObject bo = businessObjectDAO.loadBusinessObject(id);
...
  bo.executeBusinessStrategy(businessStrategy);
...

Code snippet taken from BusinessObject:

...
public void executeBusinessStrategy(BusinessStrategy businessStrategy) {
  businessStrategy.execute(this);
}

What do you think about this?
Are there any issues related with our architecture?

thomas

[Rod Johnson]

Oliver, thanks for posting that code. I think we should definitely consider including something based on it in Spring 1.2. (Btw, "setPersistantClassBeanNames" should be "setPersistentClassBeanNames").

As I've said before, my main concern is the performance. I do mean to optimize the prototype functionality where possible in 1.2, but need to be able to quantify the resulting performance.

If you were to contribute this code as a basis, that would be great. If you or someone else could also contribute a simple app using it (or use case involving one or two mapped classes, possibly returning large result sets) that we could profile and benchmark that would be even better. I could then verify the actual overhead, and the effect of my optimizations.

[Ben Alex]

Ollie's approach is quite interesting and I'm sure it's helpful in many situations. I found Fower's POEAA p 134, "Service Layer: How It Works" very informative. If you've got the book and are about to put everything into domain objects, may I suggest having a read of it first.

In summary it is helpful to break "business logic" into its two forms: domain logic and application logic. Domain logic deals with the problem domain alone and should be in the business objects. Application logic deals with the application responsibilities (gateways, DAOs etc) and should be in service objects.

By nature application responsibilities are probably singletons and managed in a Spring application context. They also tend to be associated with AOP concerns like transactions and security. It's therefore a natural fit and quite easy to follow this advice of using a service layer for application responsibilities.

Take an example:

Our Product class may have an updateTax(TaxRate effectiveRate), which is domain logic as it deals solely with the problem domain. We'd probably re-use our Product in other applications as it properly models the problem domain. If a requirement was then to send an email to report unusual TaxRate usages to the financial accountant, that is application logic. In this case there should be a ProductService.updateTax(Product product, TaxRate effectiveRate) so that ProductService can send the email. Of course we could have Product include a setEmailGateway(EmailGateway) method, automagically populated from Spring, but then Product is not re-usable in other applications as we've "polluted" it with application logic and application interfaces. It gets even more ugly as you add more and more application services. Take security. If we decide only a person with ROLE_ACCOUNTANT for a given product family can update the tax rate, you now also need Product to contain setAccessDecisionManager, setAclManager and some way of ensuring the ContextHolder contains a valid Authentication object. Your previously simple updateTax method will have become an ugly non-resuable mix-match of application and domain logic.

So AFAIK there is nothing technically preventing injecting collaborators into domain object instances. But it seems easier to me to just stick with what Spring makes easy and allows maximum reuse: delineation between application and domain logic, in service layers and domain objects respectively. If you need a singleton collaborator or AOP functionality (security, transactions), it's probably application logic.