aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes EJB 3.1 Cookbook - where to use entities Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB 3.1 Cookbook - where to use entities" Watch "EJB 3.1 Cookbook - where to use entities" New topic
Author

EJB 3.1 Cookbook - where to use entities

Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Richard!

Good to have another book on EJB 3.1 to choose from! It certainly looks interesting. I was wondering what you think of using Entities: should we use them only in the "Model" layer and use DAO's (or something similar) in the "View/Controller"-layer? Or do you think it is okay to pass them through the service facade and just use the same Entity objects throughout the entire application? Or do you think this choice should depend on the size of the application or maybe some other metric?

Best regards,
Bart Kummel


SCJP 1.4 | SCJD 1.6 | Visit my website | Author of the book Apache MyFaces 1.2 Web Application Development
Richard Reese
author
Ranch Hand

Joined: Jul 13, 2011
Posts: 84
    
    5

Bart,

Entities provide a safe means of concurrently accessing a data store. Using multiple entities against the same data store could result in the use of multiple connections depending on the data store server. Using multiple entities increases the burden on the EJB container. In addition, your application could be distributed across multiple servers. If I understand your question correctly, I would check the configuration of your environment to answer some of these questions. In general, using the same entity objects is preferred.


Richard Reese
Java 8 New Features: A Practical Heads-Up Guide
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Richard,

Thanks for your reply. Let me rephrase my question a bit. Suppose we have a PersonServiceFacade, that has a getPersonById(...) method. Now when I call that method from my View/Controller layer, e.g. from a JSF/CDI managed bean, what I get is a detached Person entity. I'm fine with that; I just let the user manipulate the values within the object via a form and merge and persist the Person object as the user presses the "save" button.

However, sometimes people tell me it is not good to work with detachted entities directly. Those people either create DAO objects or manipulate the entities only via methods on the PersonServiceFacade. (E.g. setPersonName(Person person, String newName)) I don't see much harm in manipulating detached objects, as soon as you don't forget to merge them. On the other hand, creating extra DAO objects or similar strategies seems to introduce much boilerplate / repeated code.

What's your opinion on this? Can you give me some good arguments to settle this discussion once and for all?

Best regards,
Bart
Richard Reese
author
Ranch Hand

Joined: Jul 13, 2011
Posts: 84
    
    5

I don't see anything wrong with your approach, however, as you stated, don't forget to merge. Creating a DAO or using set type methods is extra work. You may be aware of the Transfer Object pattern which is effectively this approach (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Richard,

Thanks again for your reply. Good tom mention the Transfer Object pattern in this regard. Although I knew the pattern, I did not realize that my approach in fact implements this pattern. Thanks!

Best regards,
BArt
Jan Groth
Ranch Hand

Joined: Feb 03, 2004
Posts: 456
Being on JEE 6, it's actually possible to get a good step further and benefit from the combination of advantages of CDI and EJB 3.1:

You can use an extended persistence context and bind the entitymanager to a (long running) CDI-conversation. Thereby all entities are kept attached (and managed) for the whole unit of work. The persistence context will flush whenever a transaction commits - something you can easily control in your facade (SFSB). This not only saves the costs of re-attaching entities on each request (not possible without db-lookups), but also uses the persistence context as a native first level cache, and also allows lazy loading in the view.

I find this approach far superior than reusing patterns and best practices from the times when JEE still had a "2" in the middle (and concepts like extended persistence context had yet to be invented) ;-)
Jan Groth
Ranch Hand

Joined: Feb 03, 2004
Posts: 456
Bart Kummel wrote:I was wondering what you think of using Entities: should we use them only in the "Model" layer and use DAO's (or something similar) in the "View/Controller"-layer? Or do you think it is okay to pass them through the service facade and just use the same Entity objects throughout the entire application? Or do you think this choice should depend on the size of the application or maybe some other metric?


If I may add my two cents:

I would not implement model transformations unless you have an explicit requirement which can only be fulfilled by it (Security might be such a thing). But if we are talking about "just" passing entities from the business layer to view, I would always use the same entities.

This
  • saves a lot of transformation glue code
  • makes your life easier in terms of debugging and future enhancements
  • allows to use concepts like lazy-loading in the UI layer


  • The often-heard argument that model transformations are required for a "good" decoupling of layers and as such are essential for "good" architectures is best answered by asking if there are any concrete plans to exchange any layers in the near future. If the answer is somehow vague, than make an official note that you'll start implementing the model transformation the day the layer exchange is requested... :-)
    Bart Kummel
    author
    Ranch Hand

    Joined: Nov 30, 2007
    Posts: 81
    Hi Jan,

    Thanks for your additions to the discussion, they're actually quite useful. I totally agree with your point about leveraging the benefits of CDI conversations.

    Jan Groth wrote:The often-heard argument that model transformations are required for a "good" decoupling of layers and as such are essential for "good" architectures is best answered by asking if there are any concrete plans to exchange any layers in the near future. If the answer is somehow vague, than make an official note that you'll start implementing the model transformation the day the layer exchange is requested... :-)


    This is exactly the type of discussion I meant . Glad to hear that I'm not the only one who gets involved in this type of discussion. Reminds me of the saying "premature optimization is the root of all evil"... ;)

    Best regards,
    Bart
     
    Consider Paul's rocket mass heater.
     
    subject: EJB 3.1 Cookbook - where to use entities