Entity Framework - Self Tracking Entities

Question

If using STE's with entity framework, when building the client application (say web site) which will receive the entities via wcf, is it necessary to reference the model dll assembly (which contains the definitions of the classes?) to achieve all the features of STE's?

Alternatively, when you just use the proxy classes that are generated from the service wsdls', what features do you lose?

Answer 1

STEs are designed to start tracking after deserialization, the self tracking functionality is generally useful for determining what has changed so that you only pass the necessary changes of the wire.

Self Tracking Entities was a fashionable implementation of EF introduced in v4 of the Entity Framework. It was superseded by DbContext (server) and ODataClient (client) in EF6 where the Tracking context is decoupled from the Entity itself.

STE models generally mix a rich set of business logic inside the model classes that are designed for RPC style coupling where the dlls are expected to be used on the client side instead of generated proxy classes.

If you use generated proxy classes from the WSDL or $metadata on the client, any custom business logic within the model does not exist on the client. This business logic would be in the form of code inside property setters or change handlers that either validates, rejects or reacts to changes. The only way to get this complex logic onto the clients is to distribute the dlls to client-side developers, otherwise you must rely on their ability to replicate it when needed.

STEs offered a remote code solution that provided a mechanism for publishing server-defined business logic that would be executed on the client, with the expressed intent of validating business rules and reducing the bytes sent across the wire.

You can still generate simple CRUD change tracking on the client but if you end up using generated proxy classes, the server definition is totally ignored, you lose any rich tracking and validation code that might be defined on the server.

When client-side generated proxies are used, there are no assumptions that can be made from the server. Because it is always possible in API projects for the client to choose NOT to use your dlls and to generate their own proxies anyway, it is important that you re-validate, sanitise and verify all inputs from the client.

It is not practical to send the change history across the wire, most STE implementations use the tracking to determine what information to send, but the server does not receive the change stack, instead it is expected that the server logic would either assume the entire payload represents the complete state that should be stored (by attaching the entity to the server context) or it will need to generate it's own change graph by comparing to the current value stored on the server.

STE authors will make the client models available if they think it is necessary, in general if the DLLs are provided it should save a lot of time and management if you use them.

STEs have gone out of fasion, largely due to the maintenance burden on the API developer to provide compliant DLLs but also due to low adoption rates by clients who generally only need a sub-set of the API and so are more likely to accept a solution that is decoupled from the server's physical implementation and structure. EF and OData have evolved to address the original issues that the STE Framwork was designed to address.

Answer 2

Not sure 100%, but STEs are designed to start tracking after deserialization. If you end up using generated proxy classes, you're going to lose all that tracking code on the client side. I do not believe the generated entities can track changes that happen at the time the entities are rehydrated on the server side from client proxies, so I'd definitely reference the model assembly.