Breeze.js mixes DTO and objects

Question

In Ward's article "Breeze Server: Have Your Way ":

A typical business application has at least 200 domain model types. 90 +% of the time when the form of data that I send over the wire is the same as the form of the object in my business model.
...
When the form of the client object does not align well with the form of the business object on the server side, I can switch to DTO for this special case.

It hits a nail right on the head for our application, but what's the best way to switch only some objects for DTO?

For example, our custom object contains sensitive properties that should not be exposed to the client. It also has associated data that is retrieved from other systems and returned to the client, which ideally should simply be additional properties on the user's client objects. The user seems like the perfect candidate for switching to DTO.

If the user was an isolated object, this might be easier, but the problem is that the user is referenced mostly everywhere in the model. For example, almost every object has a CreatedBy property.

Is there a way to switch the User object for a user DTO in the model? For all other model objects that reference users, we still need to be able to load them with advanced user properties, query them for these user properties, and save them with changes to these user properties.

I'm not sure how to do this, except creating a large DTO model that is 95% identical to the entity model and has some code / mapping structure between them. But, as Ward says in this post , “I don’t like DTO for every type, it’s redundant, which can ruin the performance.”

Answer 1

You are in good company. Similar questions arise. Hope you get a better guide soon.

In the short term (if you are a .NET developer), you can find some tips in the DocCode sample. Find "ProductDto". DocCode does not show how you save the changes, so I will have to hold it until another time.

The script can be easily simple.

Step # 1: use custom DbContext

Start by subclassing your DbContext business model. Add an override to this subclass in your OnModelCreating and teach it to ignore User properties that should not be part of the model.

 protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<User>().Ignore(u => u.whatever); ... base.OnModelCreating(modelBuilder); } 

Now refer to the IT obtained by DbContext when communicating with clients.

Please note that this is due to very little code and is easy to maintain. This does not stop you from using the DbContext database, which retains full access to all User properties.

Step # 2: configure JSON.NET to exclude these properties from serialization

Follow the James Newton King Guide . Take a look, in particular, at IContractResolver if you do not want to decorate / pollute your User class with the [JsonIgnore] attribute. James is the author of JSON.NET.