Book suggestion on this DDD concept specific to ASP.NET MVC and JSON? [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.

Closed 8 years ago.

Improve this question

I am looking for a book or blog entry on the following DDD concepts, something specific to MVC and C# code. Quick summary: partially populated domain models from special repository methods and sending only changed domain model properties as JSON back from the client.

More details:

If you have a Customer object but need a drop down list having only customer number and customer name, you would create a special Repository method to return a full IList of Customer but only populate the customer ID and the Customer name, leaving other properties null or empty. This saves creating tons of special classes for a view model.
If you are editing a Customer, you would cache the Customer object in a session variable at the server then JSON serialize the View Model containing the Customer DDL and the first customer object for the client, possibly embedding the JSON in the first Html coming from the server. It would be really nice to have the JSON resolve to the MVC controller method "object parameters" (reassembly of the post data to an object parameter from JSON).
The client (JavaScript) instantiates the customer object and binds the object properties to the corresponding HTML input statements of the same name. When one changes, the other changes. Also throw in a template concept for IList objects. It also flags the customer object property as dirty when the input value changes (event).
Up开发者_如何学JAVAon submit, only the changed (dirty) object properties are serialized to JSON and sent back to the server. Unchanged properties are simply left out. The server will combine the cached customer object with the partial JSON customer object (changes only), submitting the resulting Customer object to the repository to persist.

It's a really great concept. I would like to read about the theory and get a to-do list.

(I am not providing a book recommendation. I'm only posting an answer because I ran out of space in the comment box).

I don't think this "pattern" has much to do with DDD, but it all sounds so appealing, doesn't it?

I have to say, though, that this screams "I'm going to work so long and hard on this awesome framework that will in the end net little to no performance benefit, but I'll wedge it into my application because I spent so long on it." Either that, or trying to implement this will prevent the application from actually being realized.

ASP.NET MVC model binding does a lot of what you're aiming for, albeit not in precisely the way you describe. What it doesn't do is the "only send back dirty properties" bit, but to be honest any web application that is going to net a benefit from this after all the client-side logic is more than likely poorly designed on another level (data not paged; individual views too heavy).

I don't see any benefit from caching the object in session and this is anathema to the ASP.NET MVC system anyway.

Loading only needed objects/collections from a repository is a solved problem using a first-class object-relational mapping technology, such as NHibernate.

Save the JSON for asynchronous operations.

All of this aside, what you are describing could be loosely considered as a set of optimizations that could be implemented in a piecemeal fashion, once the core of the application is working. This ensures that you deliver some value, and only do the substantial work of implementing these optimizations (if they even prove to be such) if performance is not acceptable.

Phil Haack has much of this in his blog, talking about MVC 2 Futures, JSON validators, Json2.js, and the like. It all works very well. This is the post.