本书针对ASP.NET MVC和JSON特有的DDD概念提出建议？

Question

我正在寻找关于以下DDD概念的书籍或博客条目，这些概念是特定于MVC和C＃代码的内容。快速总结：部分填充来自特殊存储库方法的域模型，并仅将更改后的域模型属性作为JSON从客户端发回。

更多细节：

• 如果你有一个客户对象，但需要一个下拉列表，只有客户数量和客户的名字，你会创建一个特殊的库方法来返回客户的完整的IList，但只填充客户ID和客户名称，将其他属性留空或空。这节省了为视图模型创建大量特殊类。

• 如果您要编辑客户，您需要将客户对象缓存到服务器的会话变量中，然后JSON序列化包含客户DDL和客户端的第一个客户对象的视图模型，可能会将JSON嵌入到第一个来自服务器的Html。将JSON解析为MVC控制器方法“对象参数”（将发布数据从JSON重新组合为对象参数）将会非常好。

• 客户端（JavaScript）实例化客户对象并将对象属性绑定到相同名称的相应HTML输入语句。当一个变化时，另一个变化。还要为IList对象引入一个模板概念。它还会在输入值更改（事件）时将客户对象属性标记为脏。

• 提交后，只有已更改（脏）对象属性被序列化为JSON并发送回服务器。未更改的属性完全被忽略。服务器会将缓存的客户对象与部分JSON客户对象（仅更改）合并，并将生成的Customer对象提交到存储库以保留。

这是一个非常棒的概念。我想了解这个理论并获得待办事项清单。

Answer 1

Phil Haack在他的博客中谈论了MVC 2期货，JSON验证工具，Json2.js等等。这一切都很好。 This is the post。

Answer 2

（我没有提供图书推荐，我只发布了一个答案，因为我的空间在评论框中用完了）。

我不认为这种“模式”与DDD有很大关系，但它听起来很有吸引力，不是吗？

但是我不得不说，这个尖叫声“我要在这个非常棒的框架上工作这么长时间并且很努力，最终网络几乎没有性能优势，但是我会将它嵌入到我的应用程序中因为我花了这么长时间。“要么这样做，要么试图实现这一点将会阻止应用程序真正实现。

ASP.NET MVC模型绑定完成了很多目标，尽管不是完全按照您描述的方式。它没有做的是“只发回脏属性”一点，但说实话，任何Web应用程序都将从这个网络中受益，毕竟客户端逻辑在另一个层面上设计得很差（数据未分页;个别视图太重）。

我没有看到在会话中缓存对象的好处，这无论如何都是对ASP.NET MVC系统的诅咒。

使用NHibernate等一流的对象关系映射技术，从存储库中仅载入需要的对象/集合是一个解决的问题。

保存JSON以进行异步操作。

除了所有这些，您所描述的内容可以被粗略地视为一组优化，可以在应用程序的核心工作后以零碎的方式实现。这确保了你提供了一些价值，并且只有在实现这些优化（如果它们甚至被证明是这样）的情况下做实质性工作，如果性能是不可接受的。