StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<ol> <li>This is probably the best approach from those you mentioned but it will require the biggest effort. First of all you will have to make your entities serializable by WCF = you will have to modify generator to use <code>DataContract(IsReference = true)</code> and <code>DataMember</code> attributes because otherwise you will get cyclic reference exception when serializing object graph (entity with its relations where both principal and dependent have navigation property to each other). Once using object graphs you will also have to make your own change tracking or data merging because <a href="https://stackoverflow.com/questions/3635071/update-relationships-when-saving-changes-of-ef4-poco-objects/3635326#3635326">you will not know about changes made on client</a>. If you don't plan to transfer object graphs but only single objects or list of the same objects you should be OK with this approach.</li> <li><code>EntityObject</code> is specific to Entity Framework and exposing it to clients is a bad idea. It is by default serializable by WCF but it also transfers EF specific information like <code>EntityKey</code>. The point of service should be to hide its internal implementation and exposing <code>EntityObject</code> based entities is violation of that rule. It also doesn't solve change tracking problem.</li> <li>STEs are designed for the <a href="https://stackoverflow.com/questions/5091974/what-is-the-purpose-of-self-tracking-entities/5092097#5092097">scenario where you want to know about changes in object graphs</a> made on clients but they are not a silver bullet. Services and clients should share only contract describing exchanged messages. STEs violate this rule because they contain logic and client must know and use this logic. STEs are based on sharing entity assembly between service and all clients = <a href="https://stackoverflow.com/questions/3814706/self-tracking-entities-vs-poco-entities/3815968#3815968">clients must be .NET application</a> or the same logic must be reimplemented on non-.NET platform. They also always transfer whole object graph - if you load 100 entities in graph send them back to client and client will make change to single entity in graph it will by default send all 100 entities back to the service. </li> <li>POCO generator is generally the same as the first approach. It just uses ObjectContext API instead of DbContext API. Fixup methods are service specific and client will not know about them.</li> </ol> <p>The last approach is using custom non entity classes (DTOs = Data transfer objects) and hide conversion between DTOs and entities in your service. That will allow you to create more complex and suitable set of objects but it will also make your application more complex and increase development complexity. This will be also option in case of implementing your own change tracking.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload