DAO Reference Inside an Entity Domain Object?

[Savagearts]

Good discussions. I'd prefer that Domain object hold a DAO object.
It's so hard to inject DAO object into a domain object because domain objects are out of spring container's control. But we may use "Service Locator" to get a dao reference. The code looks like this:

class MyParentEntity 
{ 
	private MyDao myDao = (MyDao)ApplicationContextHolder.getContext().getBean("myDao");
  public int getSum( FilteringParams params) 
  { 
    return myDao.getSum(params, this); 
  } 
}

AOP may faciliate Domain object's transaction demarcation. AspectJ is my choice.
[/code]

[cepage]

DI on list() and such works, of course - the whole thing would be useless otherwise.

Are you saying that because that's how you think it should work, or because you have tried it?

In my tests with actual code, DI works on session.load() and session.find(), but not query.list().

[dejanp]

DI on list() and such works, of course - the whole thing would be useless otherwise.

Are you saying that because that's how you think it should work, or because you have tried it?

In my tests with actual code, DI works on session.load() and session.find(), but not query.list().

In my tests that use HibernateTemplate.find() which internally uses query.list() it works. Hibernate 3.

If it doesn't work in some version I'd consider it a Hibernate bug really.

[cepage]

In my tests that use HibernateTemplate.find() which internally uses query.list() it works. Hibernate 3.

Thanks, I will give this a try under Hibernate3. Anyway, my original point was that this is a half-implemented solution (that we can get working with some hacking) in the sandbox, and right now a finished solution is not scheduled until 1.4, probably a year off.

I think smart people can reasonably disagree on this issue, but let's say you have two possible approaches on how to delete a user record from within a process object:

user.remove()

or

_userDao.remove(user)

In my opinion, the second approach introduces a bad code smell. You should minimize the number of collaborators and dependencies in a given class. The first approach has one, the second approach has two.

More to the point, the process was already dependent on the user object to begin with (it had a reference to the user object). The second approach introduces a brand new dependency on the UserDao interface which didn't need to be there before.

(In my apps, only Spring-managed factories and domain objects know about the DAOs. My process objects never directly reference the DAOs)

So, I feel the first approach promotes greater application stability by reducing the number of external dependencies.

[cepage]

But we may use "Service Locator" to get a dao reference. The code looks like this:

class MyParentEntity 
{ 
	private MyDao myDao = (MyDao)ApplicationContextHolder.getContext().getBean("myDao");
  public int getSum( FilteringParams params) 
  { 
    return myDao.getSum(params, this); 
  } 
}

Yeah, I fell into this trap, and then got killed in my integration testing. As soon as I start using something like AbstractDependencyInjectionSpringContextTest that doesn't use the above approach to procure the ApplicationContext, you start ending up with two ApplicationContexts intermingling in your integration tests. Singletons suddenly aren't singletons anymore, and bad things happen.

I'm guessing that this sort of scenario is why the gurus discourage the use of ContextSingletonBeanFactoryLocator.

[Savagearts]

AbstractDependencyInjectionSpringContextTest[/b] that doesn't use the above approach to procure the ApplicationContext, you start ending up with two ApplicationContexts intermingling in your integration tests. Singletons suddenly aren't singletons anymore, and bad things happen.

I'm guessing that this sort of scenario is why the gurus discourage the use of ContextSingletonBeanFactoryLocator.

I often write a ApplicationContextHolder Bean that implements ApplicationContextAware interface. This bean simply holds a ApplicationContext reference. So whenever using AbstractDependencyInjectionSpringContextTest, Everything is ok.

public class ApplicationContextHolder implements ApplicationContextAware{
    private static ApplicationContext applicationContext;

    public static ApplicationContext getContext(){
        return applicationContext;
    }

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        ApplicationContextHolder.applicationContext = applicationContext;
    }
}

[manifoldronin]

Yeah, I fell into this trap, and then got killed in my integration testing. As soon as I start using something like AbstractDependencyInjectionSpringContextTest that doesn't use the above approach to procure the ApplicationContext, you start ending up with two ApplicationContexts intermingling in your integration tests. Singletons suddenly aren't singletons anymore, and bad things happen.

I'm guessing that this sort of scenario is why the gurus discourage the use of ContextSingletonBeanFactoryLocator.

I wrote an AppContextCollector that is basically a (true) singleton map that passively collects contexts:
http://www.digizenstudio.com/blog/20...unintrusively/

[manifoldronin]

I just posted another blog entry summarizing an Aspectwerkz-based approach to intercept a getXXXDAO call and return a DAO bean reference:
http://www.digizenstudio.com/blog/20...omain-objects/

It's not strictly "injecting" per se, as it doesn't need the domain object to have a field for the reference being injected. The basic idea is the same as the lookup-method in Spring.

Let me know if I'm slipping too far into the dark side...

[Colin Yates]

Nice simple solution.

Still not *ideal*, but getting there

[cepage]

Thanks, Jing and Savage. That's very helpful.