StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6686361
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-07-13T22:16:00.187
FavoriteCount
0
LastActivityDate
2011-07-13T22:16:00.187
LastEditDate
LastEditorUserId
0
OwnerUserId
396631
ParentId
6685909
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
I would actually take the following approach: Have the models (POCOs) for example in a project that is referenced only by your DAL and BLL. That will ensure that you can work with them in the DAL layer and apply the business logic to them in the BLL. For the presentation layer I would create DTOs (Data Transfer Objects) which will be carrying only the data that you need for a specific scenario/entity. The translation between the DTOs and POCO, I would place in the BLL. I can think of the following pros & cons to this approach: 1) Pros -- Full separation between presentation and core layers (BLL, DAL). Your DTOs will be independent from the database (POCOs) which means that whatever changes you do to the database, you will only need to change that in the translations layer. -- Stable BLL API -- Validation separation - you can implement validation on the DTOs for the presentation and on the POCOs for the BLL. 2) Cons -- Translation rules for each POCO-to-DTO. This will inevitably add some complexity to your code, but I believe that it is a good payoff. -- Performance overhead. The translation and instantiation of DTOs and POCOs will add some overhead to your application. Depending on your requirments and machine capabilities you can decide whether this is a good payoff. I also advise you to take a look at some mapping libraries that allow easy mapping/translation between different types of objects. In my opinion the best one is <a href="http://nuget.org/List/Packages/ThisMember/0.7.0" rel="nofollow">ThisMember</a> both in simplicity and performance. Regards
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHiding Entity Model classes from Presentation Layer
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USsTodorov
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
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.