1

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

更多细节：

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

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

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

  • 提交后，仅将更改的（脏）对象属性序列化为 JSON 并发送回服务器。未更改的属性被简单地排除在外。服务器会将缓存的客户对象与部分 JSON 客户对象（仅限更改）组合，将生成的客户对象提交到存储库以进行持久化。

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

4

2 回答 2

2

（我不提供书籍推荐。我只是发布答案，因为我在评论框中的空间不足）。

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

不过，我不得不说，这尖叫着“我将在这个很棒的框架上工作这么长时间和努力工作，最终将几乎没有性能收益，但我会将它楔入我的应用程序，因为我花了这么多长此以往。” 无论是这样，还是试图实现这一点，都会阻止应用程序的实际实现。

ASP.NET MVC 模型绑定完成了很多您的目标，尽管并非完全按照您描述的方式。它没有做的是“只发回脏属性”位，但老实说，在所有客户端逻辑很可能在另一个层面上设计不佳之后，任何将从中受益的 Web 应用程序（数据未分页；个别视图太重）。

我看不出在会话中缓存对象有什么好处，无论如何这对 ASP.NET MVC 系统来说都是一种诅咒。

使用一流的对象关系映射技术（例如 NHibernate）从存储库中加载只需要的对象/集合是一个已解决的问题。

保存 JSON 以进行异步操作。

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

于 2010-07-09T03:03:53.017 回答
0

Phil Haack 在他的博客中有很多这样的内容，谈论 MVC 2 Futures、JSON 验证器、Json2.js 等。这一切都很好。 这是帖子。

于 2010-10-31T03:20:30.007 回答