This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB 3.1 Cookbook - where to use entities

 
Bart Kummel
author
Ranch Hand
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Richard Reese
author
Ranch Hand
Posts: 84
5
Eclipse IDE Firefox Browser Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bart Kummel
author
Ranch Hand
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 84
5
Eclipse IDE Firefox Browser Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 456
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 456
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 81
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic