Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
  • 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 be a huge deal, but I don't want to switch to STEs only to find out it doesn't work for us.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

The main argument against "self-tracking entities" (or the ActiveRecord pattern, as I've heard it called) is that it mixes persistence logic into your domain model. The POCO alternative gives you better separation of concerns.

Consider the case where you might have your model operating in a client or server environment. You could abstract your persistence logic into a Repository interface. When running in the server environment, you could inject your model with a Repository that persists the entities to the database, but when on the client, you could inject the same model with a Repository that persists the entities over a WCF service. Your unit test logic can also inject a Mock Repository.

The advantage of the ActiveRecord pattern is that there is usually a lot of automation involved, so you point your IDE at a database, and it builds all your entities for you. With POCO entities, you usually do a bit more coding yourself. Personally I prefer the flexibility that this offers with the POCO alternative.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.