我有一个包含三层的asp.net mvc应用程序： - 具有实体和存储库（nhibernate）模式的数据层 - 具有服务（功能）的服务层，与数据层通信。 - 使用asp.net mvc应用程序的ui层，它与服务层通信。
问题是我的实体中的数据与我的视图中的数据不同。 所以我使用自定义形状的ViewModels。但我不喜欢我在服务层和视图模型之间映射的方式。 一切都发生在控制器动作中。我正在使用AutoMapper，但我认为有太多的意大利面条代码。 让我举个例子：
1。）我正在进行用户注册过程。我有一个FirstName，LastName，Email，OpenId输入映射到相同的 ViewModel中的属性。但是，我需要不同的实体来存储这些数据（一个用于用户，一个用于openid身份 - 用户可以拥有多个openid身份）。 因此，在我的控制器操作中，我在视图模型和用户实体之间有一个映射（AutoMapper），在视图模型和openid实体之间有一个映射（AutoMapper）。之后 我用服务功能保存每个实体。
我想念一些东西 - 比如自定义DTO（我不认为应该在服务层和Web层之间共享视图模型），它将在Web和服务层之间传递。
2.。）我在应用程序中有搜索功能。从控制器操作中，我调用服务层，该服务层返回与搜索条件匹配的文档实体列表。 但问题是我还想为每个结果显示类别（不同的实体）。因此，在控制器操作中，我在结果之间循环并添加类别信息 到视图模型中的IDictionary结构。
我也想念这里的东西 - 再一些DTO将返回对的列表（新对象）：文档，类别。
DTO是正确的模式吗？我应该看看DDD吗？任何相关材料将不胜感激。
非常感谢！
答案 0 :(得分：0)
我认为您在应用程序架构中缺少一个图层，但听起来您缺少某些类型（类）。
你应该创造更多的DTO吗？不，我认为这不是一个好主意。 IIRC，DTO的最初定义是跨越流程边界传输数据。 WCF数据合同是DTO的一个很好的例子。但是，由于DTO只是消息，因此它们不包含任何行为。如果您在DTO上建立内部API，则会导致Anemic Domain model。
您仍然应该认真考虑在应用程序中添加新类型以满足您的需求。这些类型应该去哪里？
这取决于。如果您可以说有问题的类型封装了通用概念，则它属于域模型。如果它仅用于支持给定（用户）接口，则它属于该层。
在第二个示例中，您需要将文档和类别组合在一起，尽管它们是独立的实体。这种组合是否包含了一个反复出现的概念？如果是，则它属于您的域模型。如果没有，它就属于你的UI层。
如果有疑问，请将新类型放在外层（您的UI图层）中。如果事实证明这是一个比你想象的更通用的概念，你可以相对轻松地将它移动到你的领域模型。移动另一种方式更难，因为该类型可能已经污染了域模型，因此从外层开始是最安全的选择。