我正在寻找关于以下DDD概念的书籍或博客条目，特别是MVC和C＃代码。快速摘要：从特殊存储库方法部分填充的域模型，并仅从客户端发回更改的域模型属性作为JSON。
更多详情：
如果您有一个Customer对象但需要一个只有客户编号和客户名称的下拉列表，您可以创建一个特殊的Repository方法来返回Customer的完整IList，但只填充客户ID和客户名称，将其他属性保留为null或为空。这样可以节省为视图模型创建大量特殊类。
如果您正在编辑Customer，则将Customer对象缓存在服务器的会话变量中，然后JSON序列化包含Customer DDL的View Model和客户端的第一个客户对象，可能会嵌入JSON。来自服务器的第一个Html。将JSON解析为MVC控制器方法“对象参数”（将后期数据重新组装为来自JSON的对象参数）真的很好。
客户端（JavaScript）实例化客户对象，并将对象属性绑定到相同名称的相应HTML输入语句。当一个改变时，另一个改变。同时为IList对象引入模板概念。当输入值更改（事件）时，它还将客户对象属性标记为脏。
提交后，只有已更改的（脏）对象属性被序列化为JSON并发送回服务器。简单地忽略了不变的属性。服务器将缓存的客户对象与部分JSON客户对象（仅更改）组合在一起，将生成的Customer对象提交到存储库以保持不变。
这是一个非常棒的概念。我想阅读有关该理论并获得待办事项清单。
答案 0 :(得分：2)
（我没有提供图书推荐。我只是发布了答案，因为我在评论框中用完了空间。）
我不认为这种“模式”与DDD有很大关系，但它听起来都很吸引人，不是吗？
但是，我不得不说，这种尖叫声“我将在这个令人敬畏的框架上工作这么长时间并且很难，最终网络几乎没有任何性能优势，但我会把它融入我的应用程序，因为我花了很长时间才对它说。“要么是这样，要么试图实现这个将阻止应用程序实际实现。ASP.NET MVC模型绑定可以实现您的目标，尽管不是您所描述的方式。它没有做的是“只发送回脏属性”位，但说实话，任何Web应用程序都将从此获益，因为所有客户端逻辑很可能在另一个层次上设计得不好（数据没有被分页;个人意见太重了。
我认为在会话中缓存对象没有任何好处，这无论如何都是ASP.NET MVC系统的诅咒。
使用第一类对象关系映射技术（例如NHibernate），只从存储库加载所需的对象/集合是一个已解决的问题。
保存JSON以进行异步操作。
除此之外，一旦应用程序的核心工作，您所描述的内容可以被宽泛地视为一组优化，可以以零散的方式实现。这可以确保您提供一些价值，并且只有实现这些优化的实质性工作（如果它们甚至证明是这样的话），如果性能不可接受的话。
答案 1 :(得分：0)
Phil Haack在他的博客中有很多内容，谈论MVC 2 Futures，JSON验证器，Json2.js等。一切都很好。 This is the post