How would I know if I should use Self-Tracking Entities or DTOs/POCOs?

Question

What are some questions I can ask myself about our design to identify if we should use DTOs or Self-Tracking Entities in our application?

Here's some things I know of to take into consideration:

• We have a standard n-tier application with a WPF/MVVM client, WCF server, and MS SQL Database.
• Users can define their own interface, so the data needed from the WCF service changes based on what interface the user has defined for themselves
• Models are used on both the client-side and server-side for validation. We would not be binding directly to the DTO or STE
• Some Models contain properties that get lazy-loaded from the WCF service if needed
• The Database layer spams multiple servers/databases
• There are permission checks on the server-side which affect how the data is returned. For example, some data is either partially or fully masked based on the user's role
• Our resources are limited (time, manpower, etc)

So, how can I determine what is right for us? I have never used EF before so I really don't know if STEs are right for us or not.

I've seen people suggest starting with STEs and only implement DTOs if they it becomes a problem, however we currently have DTOs in place and are trying to decide if using STEs would make life easier. We're early enough in the process that switching would not take too long, but I don't want to switch to STEs only to find out it doesn't work for us and have to switch everything back.

Gould

Answer 1

If I understand your architecture, I think it is not good for STEs because:

• Models are used on both the client-side and server-side for validation. We would not be binding directly to the DTO or STE

The main advantage (and the only advantage) or STEs is their tracking ability but the tracking ability works only if STE is used on both sides:

• The client query server for data
• The server query EF and receive set of STEs and returns them to the client
• The client works with STEs, modifies them and sends them back to the server
• The server receives STEs and applies transferred changes to EF => database

In short: There are no additional models on client or server side. To fully use STEs they must be:

• Server side model (= no separate model)
• Transferred data in WCF (= no DTOs)
• Client side model (= no separate model, binding directly to STEs). Otherwise you will be duplicating tracking logic when handling change events on bounded objects and modifying STEs. (The client and the server share the assembly with STEs).

Any other scenario simply means that you don't take advantage of self tracking ability and you don't need them.

What about your other requirements?

• Users can define their own interface, so the data needed from the WCF service changes based on what interface the user has defined for them.

This should be probably possible but make sure that each "lazy loaded" part is separate structure - do not build complex model on the client side. I've already seen questions where people had to send whole entity graph back for updates which is not what you always want. Because of that I think you should not connect loaded parts into single entity graph.

• There are permission checks on the server-side which affect how the data is returned. For example, some data is either partially or fully masked based on the user's role

I'm not sure how do you want actually achieve this. STEs don't use projections so you must null fields directly in entities. Be aware that you must do this when entity is not in tracking state or your masking will be saved to the database.

• The Database layer spams multiple servers/databases

It is something that is not problem of STEs. The server must use a correct EF context to load and save data.

STEs are implementation of change set pattern. If you want to use them you should follow their rules to take full advantage of the pattern. They can save some time if used correctly but this speed up comes with sacrifice of some architectural decisions. As any other technology they are not perfect and sometimes you can find them hard to use (just follow self-tracking-entities tag to see questions). They also have some serious disadvantages but in .NET WPF client you will not meet them.

Marder

Answer 2

You can opt STE for given scenario,

• All STEs are POCOs, .Net dynamically add one layer to it for change tracking.
• Use T4 templates to generate the STEs, it will save your time.
• Uses of tools like Automapper will save your time for manually converting WCF returned data contract to Entity or DTO

Pros for STE -

1. You don't have to manually track the changes.
2. In case of WCF you just have to say applydbchanges and it will automatically refresh the entity

Cons for STE -

1. STEs are heavier than POCO, because of dynamic tracking

Pros for POCO -

1. Light weight
2. Can be easily bridged with EF or nH

Cons for POCO -

1. Need to manually track the changes with EF.(painful)

Saccharine

Why isn't STE Pro #3 relevant to POCOs as well? – Fortenberry

I would say it is duplicity. As POCO and DTO are mostly having same properties. – Saccharine

Then your answer is misleading. It presents that point as an advantage of STEs over POCOs. – Fortenberry

Answer 3

POCO are dynamic proxied and don't play nice on the wire see this MSDN article for the workaround though. So they can be made to but IMO you're better off going STE as I believe they align nicely with WPF/MVVM development.

Mediterranean