9 Replies Latest reply on Jul 23, 2007 7:46 PM by ellenzhao

    Quick entity question

    beligum

      Hi all,

      Quick question; isn't it possible to inject a persistence-context in an entity-bean?

      @Entity
      @Name("loginEntity")
      public class LoginEntity
      {
       @In
       @Transient
       private EntityManager em;
      }
      


      thanks,

      b.

        • 1. Re: Quick entity question
          eekboom

          http://docs.jboss.com/seam/1.1GA/reference/en/html/concepts.html#d0e2489


          3.2.3. Entity beans
          Entity bean components do not support bijection or context demarcation. Nor does invocation of an entity bean trigger validation.


          • 2. Re: Quick entity question

            But sometimes you actually might want to inject entities... Domain objects often fall into this category: they may be created programmatically using the new operator, or by an ORM tool.

            Spring comes with an annotation-driven aspect that exploits the capability to allow dependency-injection of any object.

            Would it be possible to have a similar capability in Seam?

            • 3. Re: Quick entity question

              I think it would be a very bad design decision because you might inadvertently modify persistent data.

              IMHO it is better to use a manager pattern for that like Seam's home objects.

              Regards

              Felix

              • 4. Re: Quick entity question

                It doesn't have to be a repository or something that persists data, I might be interested in injecting other types of services/domain objects. I think there's value in being able to do that.

                I might have entities that are domain objects which I happen to want to inject with other domain objects that provide certain services (all my business logic is the domain layer). Shouldn't we be able to do that? Otherwise I'd have to use singletons or pass the referenced service to my domain object as a parameter in each method call (not desirable at all)


                Check out this presentation: http://www.infoq.com/presentations/rod-johnson-are-we-there-yet

                • 5. Re: Quick entity question
                  ellenzhao

                  I wanted @In for entity beans too!

                  http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114111

                  I watched the Rod presentation. In fact rich domain model is already pretty easy to do with Seam. (With the @In support in entity class, it would be even more convenient)

                  Rich Domain Model, The Seam Way:

                  Seam has out-of-box support for Drools, you can write a rule base for any entity class and use the entity's own rule base for its "rich model behaviour". This way, an entity is a totally self-contained knowledge base/expert system, it simply "knows" how to do any "rich behaviour", provided that the "how" knowledge is stored in the rule base. The rule bases can be authored in many dialects, you can author it in Java/MVEL/whatever you like, as long as there is an adapter in the drools compiler....And services can be declared in .drl files as global so any services can be used whenever entities need them. Days ago when I was refactoring my application in this way and showed a bit code to Mark Procter, he said it was the dummiest design he had ever seen, and said I'm better off with Groovy if I just want to write bean methods. But Mark, after investigating Groovy during the weekend, so far I'm not discouraged to bind a rule base to each entity. Because things like closure in Groovy is in fact rules applied to data. (Mark was extremely busy releasing Drools 4.0 GA these days, he worked almost 24/7, so I should be blamed to disturb him at such a chaotic moment....). Yes, Rete-based rule engine is only best suitable for many object/many pattern matching problem, but my entity happens to have several collections and there are some complex inter-entity pattern matching when I want an entity to "behave" something..... And please do not forget now there is the Drools Business Rules Management System out there.....Rules/Knowledge management is easier for programmers than before.....In my opinion, in fact an entity only needs to hook up two things: A database and a rule base. Database to store the "atom" properties and a rule base to store the rules of how to orchestrating different services to perform a certain entity behaviour (eg: for the Vet entity bean: rule "render myself using jsf" .... , rule "register microchip" ....). Since services are global in these rule bases, it can be really easy to change a service itself and not modifying all the rules code..... It can be a totally stupid idea, I'm also learning and just _started_ this experiment, any constructive critics and discussion are most welcome! :-)

                  • 6. Re: Quick entity question

                    Interesting. I'll dig more into Drools. Thanks a lot!

                    • 7. Re: Quick entity question

                       


                      It doesn't have to be a repository or something that persists data.


                      Not sure what you mean by that. The whole point of an entity bean is to hold persitent data.


                      I might have entities that are domain objects which I happen to want to inject with other domain objects that provide certain services (all my business logic is the domain layer). Shouldn't we be able to do that? Otherwise I'd have to use singletons or pass the referenced service to my domain object as a parameter in each method call (not desirable at all)


                      Why not inject the entity bean into the service objects? If you use Seam, you might as well do things the Seam way.

                      Regards

                      Felix

                      • 8. Re: Quick entity question

                         

                        The whole point of an entity bean is to hold persitent data


                        Sure. But an entity is at least to me a potential domain object that might contain business logic which in turn might need to get access to other services.

                        Why not inject the entity bean into the service objects?


                        Because the domain layer is potentially more reusable. Often the service layer is specific to the application.

                        I asked because I wanted to know how flexible the framework can be if I want to design an app following DDD principles.



                        • 9. Re: Quick entity question
                          ellenzhao

                           

                          "fhh" wrote:

                          Not sure what you mean by that. The whole point of an entity bean is to hold persitent data.


                          Well, I guess Manuel takes an "Entity" more like a concept, a description, a skeleton of something which has some properties and can behave.

                          "fhh" wrote:

                          Why not inject the entity bean into the service objects? If you use Seam, you might as well do things the Seam way.


                          Well, if you started out with a very clear awareness of the behaviors of the entities in your application (for most web applications, that's CRUD), it's best to inject the entity bean into the service objects. That's sending data to computation. But under some situation, you have a clear layout of the data (entity properties) but do not know how to deal with the data in an application from the beginning, you need to send computation to your data. If your entity "knows" how to crunch its own data (and inter-entity data), your entity is more reusable in a larger scale.

                          http://www.isi.edu/expect/papers/papers-ontos.html

                          http://www-ksl.stanford.edu/KSL_Abstracts/KSL-89-50.html

                          Aside from the "knowledge storing" for entities (even if we do not bind behaviours to entities using rule engine), expert systems have been very successful in hardware configuration for decades of years. Nowadays the software is becoming more and more modular, assembling software modules is pretty like assembling hardware modules. Why cannot we use expert systems to configure a big software system given well defined entities and services?

                          That said, personally I feel Seam + Drools approach is more flexible, more expressive and more intuitive than the Spring + AOP thing. Dealing with cross-cutting concerns? Rule engines are _very_ good at that.