1

I have a follow up question to the answer provided in below post

JPA Entity as JSF Bean?

I know this is the practice used in JSF applications but, I fail to understand how the approach provided in that post eliminates tight coupling? Could someone please answer?

Community
  • 1
  • 1
Srini
  • 21
  • 5

1 Answers1

0

The view is not really decoupled from it's underlying model as it's purpose it to display the internals of it's model.

However it makes a difference what this view model is and how it is attached to the view, and there are some gains in not backing the view by a persistent entity directly.

The backing bean often has to perform service calls or at least CRUD operations. Neither should be a concern of a JPA entity. The controller might also be useful for validation, access restrictions, caching etc.

A JPA entity usually does not control it's own lifecycle. Making it a backing bean would probably require the entity to control it's own transactions, at least to handle CRUD operations. This could work with an ActiveRecord implementation, but IMHO JPA entities do not lend themselves to the AR pattern too well.

In Java EE aplications, the DTO pattern is often used to decouple the persistence from the view, other external systems, or even from all layers of the application above the DAL. Entities are mapped to DTOs with more specific purposes, e.g. presenting a relevant selection of attributes from different entities to the frontend.

EDIT: If I have understood you issue correctly - you have an application where the getters of backing beans perform DB operations and cause your application to be slow. This is in fact a bad practice. The JSF lifecycle causes these getters to be called multiple times, each of the calls resulting in an unnecessary DB call.

The common practice is to fetch the complete data from DB after the backing bean was constructed and before data is displayed initially (effectively caching the data for the lifetime of the backing bean). The data should be refetched from DB only if the user explicitly refreshes it.

Please see this post for further explanation.

Community
  • 1
  • 1
kostja
  • 60,521
  • 48
  • 179
  • 224
  • Thank you for the reply but I think I am not convinced. Let us take the same User entity bean provided in the referenced post. If I remove lastname from my User entity I have to change my view as well, isn't it? – Srini May 05 '14 at 12:40
  • You're right. It's not as simple. I have rewrote the answer. Please see the edit. – kostja May 05 '14 at 13:09
  • Thank you again for the reply. I understand that view model is coupled with view and it's purpose is to display data. These view models exist in request based MVC in the form of a DTO or a plain java bean. These view models do not have any connection with entity model and they are strictly separated. A service layer creates these view model objects from entity beans. But when it comes to JSF, these are called managed beans, they wrap entity beans and does CRUD operations. IMHO, having managed bean wrap entity bean doesn't decouple entity model from view. – Srini May 06 '14 at 07:50
  • We know that view makes many getters on model to present data. If this model is a view model, calls immediately return data from view model object's attributes. If this view model is a managed bean as in the case of JSF, I see a problem here. When view makes getters on model, there is high chance that some of these calls leak through managed bean and invoke CRUD operations. You will see this situation in later stages of the application and becomes difficult to make changes or add additional behavior. Tight coupling enables efficient communication but less tolerant the solution is for changes. – Srini May 06 '14 at 07:52
  • Note: I think it is appropriate to mention that I am reviewing architecture of a JSF application which is suffering from poor usability and performance related problems. So I might sound like a critique sometimes. – Srini May 06 '14 at 07:52
  • Don't worry about constructive criticism. I am happy to learn by answering and improving, and understanding the question properly is the first step :) I hope I understand your issue better now. Please see the edit. – kostja May 06 '14 at 09:38
  • I read that post you mentioned and my problem is infact due to multiple getter callbacks from JSF. My getters lazy load data as mentioned at the end of the answer and still leak through because the bean property is reset due to some event between callbacks. How do you avoid these situations? Developers add all sorts of code as they fix bugs and soon this leakiness becomes a major bottleneck. – Srini May 06 '14 at 12:20