StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7927700
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-10-28T09:52:18.760
FavoriteCount
0
LastActivityDate
2011-10-28T09:52:18.760
LastEditDate
LastEditorUserId
0
OwnerUserId
427225
ParentId
7926463
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
Several layers doesn't lead to maintenance nightmare, moreover the less layers you have - the easier to maintain them. And I'll try to explain why. 1) Transfer Model shouldn't be the same as Data Model For example, you have the following entity in your ADO.Net Entity Data Model: <pre><code>Customer { int Id Region Region EntitySet<Order> Orders } </code></pre> And you want to return it from a WCF service, so you write the code like this: <pre><code>dc.Customers.Include("Region").Include("Orders").FirstOrDefault(); </code></pre> And there is the problem: how consumers of the service will be assured that the <code>Region</code> and <code>Orders</code> properties are not null or empty? And if the <code>Order</code> entity has a collection of <code>OrderDetail</code> entities, will they be serialized too? And sometimes you can forget to switch off lazy loading and the entire object graph will be serialized. And some other situations: <ul> <li>you need to combine two entities and return them as a single object.</li> <li>you want to return only a part of an entity, for example all information from a <code>File</code> table except the column <code>FileContent</code> of binary array type.</li> <li>you want to add or remove some columns from a table but you don't want to expose the new data to existing applications.</li> </ul> So I think you are convinced that auto generated entities are not suitable for web services. That's why we should create a transfer model like this: <pre><code>class CustomerModel { public int Id { get; set; } public string Country { get; set; } public List<OrderModel> Orders { get; set; } } </code></pre> And you can freely change tables in the database without affecting existing consumers of the web service, as well as you can change service models without making changes in the database. To make the process of models transformation easier, you can use the <a href="https://github.com/AutoMapper/AutoMapper" rel="nofollow">AutoMapper</a> library. 2) It is recommended that View Model shouldn't be the same as Transfer Model Although you can bind a transfer model object directly to a view, it will be only a "OneTime" relation: changes of a model will not be reflected in a view and vice versa. A view model class in most cases adds the following features to a model class: <ul> <li>Notification about property changes using the <code>INotifyPropertyChanged</code> interface</li> <li>Notification about collection changes using the <code>ObservableCollection</code> class</li> <li>Validation of properties</li> <li>Reaction to events of the view (using commands or the combination of data binding and property setters)</li> <li>Conversion of properties, similar to <code>{Binding Converter...}</code>, but on the side of view model </li> </ul> And again, sometimes you will need to combine several models to display them in a single view. And it would be better not to be dependent on service objects but rather define own properties so that if the structure of the model is changed the view model will be the same. I allways use the above described 3 layers for building applications and it works fine, so I recommend everyone to use the same approach.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWPF/Silverlight enterprise application architecture.. what do you do?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USvorrtex
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. This table or related slice is empty.
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.