StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12543497
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-09-22T11:53:54.820
FavoriteCount
0
LastActivityDate
2012-09-22T11:53:54.820
LastEditDate
LastEditorUserId
0
OwnerUserId
571407
ParentId
12528502
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
In my experience on a similar architecture, for a quite big project, DTOs are unavoidable and should be used when necessary. Working with detached entities, especially when they have multiple associations with other entities, not only causes performance problems due to the database loading and serialization, but also a huge complexity. Indeed, unless the code is extremely well documented, it's hard to know in the presentation layer whether a given association is loaded or not, which causes a whole lot of lazy initialization exceptions. It's even worse if you send back serialized detached entities from the presentation layer to the service layer, because then you end up with code using a mix of detached and attached entities, which makes things even more complex. My advices would thus be: <ul> <li>transfer entities from the service layer to the UI layer if the entity is simple and the UI layer doesn't need too many loaded associations. Always document which of the associations are initialized, and which are not. If too many associations, use DTOs, and ad hoc queries to load the necessary data from the database.</li> <li>transfer DTOs from the service layer to the UI layer when a big number of entities are needed (for example, the result of a search form returning O(100) results or more). Use an ad hoc query to load the requested data.</li> <li>avoid transferring entities from the presentation layer to the service layer. If you do, make sure that the first thing you do in the service layer is reloading an attached version of the entity from the database, or merging the received entity, in order to always work with attached entities. Debugging a lazy initialization exception thrown in the service layer and cause by the use of a detached entity that has been loaded several minutes ago by a previous screen is not a piece of pleasure.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POJava-EE: How to design data flow in a 3-tiered application environment?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USJB Nizet
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.