2 Replies Latest reply on Jul 21, 2008 11:02 AM by Sven Schomaker

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

    Sven Schomaker Newbie

      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

        • 1. Re: DDD with Seam; or how to inject dependencies into Entity Beans
          Jacob Orshalick Apprentice

          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.

          • 2. Re: DDD with Seam; or how to inject dependencies into Entity Beans
            Sven Schomaker Newbie
            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