Is it good pratice to use entities in JSF (view layer)

[maynard]

Is it good pratice to use entities in JSF (view layer)? And if so - should I somehow detach entities from the persistence context when my data list is ready and can be submitted for JSF rendering phases? And should I attach entities to context when I am receiving them from the view layer?

I am developing part of application where use case (master/detail data with editing) suggest that all the activies can be done in the single page with Ajax local updates. Is it OK, that I am putting my contreller (action) and associated backing beans for this page in conversation context?

At present I am reading entities at the start of conversation and then I am copying them into DTO instances and caching insides the controllers and after uses complete his or her work I am writing all the cached data (with relevant updates, made by user) into database. Is that correct approach? So - there are only 2 short transactions - when data is read and when they are saved...

[sean.tozer]

I think you're massively overthinking the issue here and basically trying to re-write Hibernate. I would have to suggest that that would be a poor idea. Don't re-invent the wheel.

If everything's being done on one page, you'd likely be better off just using the PAGE context.

The entityManager already handles all of the data caching, merging, retreiving, and updating. You don't have to worry about any of that in the vast majority of cases. That's what the persistence context is for. If you start out fighting it the whole way, you'll spend all your time doing that instead of creating an application.

It's certainly a good idea to use entities in the view layer. You've got to get the data from somewhere. I mean, what else would you do? Copy all relevant data from the entity into the controller? And then detach the entity? To what possible advantage could that be? Why not just use the persistence context and Hibernate as it's supposed to be used?

Get your trasaction mode set up however you want, update the data in the entity by binding it to fields in the view, and then flush to the database when appropriate. Done and done.

[asookazian]

It would help to show some of your code.  Remember that when using entity classes in Seam/EE5, DTO is an anti-pattern (entities are JavaBeans and thus can serve as DTOs).

The answer to your question depends on how complex the layering of your application is.  If you don't have a DAO layer, then you can reference the entities directly in the JSF views.  Otherwise, with a DAO, you may not do that.

[maynard]

Well - there are two issues that makes me use DTO's
1) when I tried to use entities in RichFaces table or other componentes, there were endless cycle in JBoss 4.3.2 server log - something about javaScript utils. There were gone when I started to uses DTO's
2) I guess, that point 1 problems was conneted with attaching and detaching entities in persistence context - but hot to do this explicitly - e.g. before sending entities to user interface. As far as understand - detaching is done automatically when entity leaves some kind of scope...

Sorry for not being quite literate, but when there are some confusion I am just trying to complete the job and deliver some visible results, but it makes me uneasy anyway.

[cbensemann]

I've had that problem before. It is an infinite recursion caused when an entity is serialized to be sent to the client (this is not java serialization - I think objects are converted to json format?? Its not really important anyway). If you have an object graph where entity A references entity B and entity B references entity A then this will cause the looping issue. I cant think of an exact example I have had to post the code and the solution but generally when I've seen that exception it means I have been trying to do something in a way that I shouldn't. I normally take a step back and realise there is no need to send whole object graphs to the client. As mentioned before it would be helpful if you could post some code and maybe we can try to come up with a different approach for you. DTOs should generally not be necessary and often just add extra complexity to your application.