DDD with Seam; or how to inject dependencies into Entity Beans

[mnemonic]

Hi all,

trying to apply some DDD insights to my current Seam
project, I discovered the apparent limitation of not
being able to inject dependencies into Entity-Beans.

While debugging NPEs on my Entity, accessing the declared
dependencies, I tried to figure out why my dependencies
were not injected.

I took a glance at the org.jboss.seam.Component source
and discovered, that Entity beans seam to be handled
differently from other component types in respect to
injecting dependencies. Am I right with my assumption,
that Entity Beans don't participate in DI from the context?

If so, is there some sane reason to handle entity beans different
from Java beans or SLSB/SFSB in respect to auto-injecting
dependencies? IMO it would be nice to be able to have dependencies
injected into the Beans.

chs Sven

[jacob.orshalick]

You can retrieve Seam components in your entities through the context but I would not generally recommended it as it reduces testability.  Essentially entities can contain (and should in my opinion) contain your business logic, but when it comes to 'Service' invocations these are intended to be performed at the Service Level with Seam.  In all cases I have run into this is really not an issue and I have successfully developed applications following the patterns of DDD with DI frameworks that follow this approach (including Seam).

Also, keep in mind that entities are only Seam components when they are instantiated implicitly by Seam.  This could lead to some odd scenarios if DI were present as entities are often explicitly created.

[mnemonic]

Hi Jacob,

thanks for your answer. Actually IMO your are right, in saying entities should contain the
business logic. If we speak of services, we could also speak of helper or utility classes that might be nice to be declared and auto-injected as seam contextual components, I think.

Sure, there are cases where you don't want to invoke services, in the good old anti-pattern sort of way, from within the entities, but rather from the Service or Application Layer.

But on the other hand, there are cases, where tying up services or utility classes in the entities itself provides for a neater programming model indeed. By not allowing DI on entities we constrain the programmer unnecessarily, IMO.

Anyway, I can surely circumvent that restriction (as I see it). I don't know what other people think of it, but I would love to have DI expanded to all classes of the model and not restrict it to certain types of beans, though I don't exactly know what would have to be done to do so.

Maybe I could file a feature request (or would I get grilled if I did so? :)) By the way, is there any official way for feature requests to get voted on?

thanks + greetings, sven