缺少我的应用程序的一部分/层

Question

我有三个层一个asp.net MVC应用程序： - 与实体和储存库（NHibernate的）图案 数据层 - 与服务（功能）服务层，它与数据层通信。 - 用asp.net mvc应用程序的ui层，它与服务层进行通信。

问题是我的实体中的数据与我的视图中的数据不同。 所以我使用自定义形状的ViewModels。但我不喜欢我在服务层和视图模型之间进行映射的方式。 一切都在控制器动作中发生。我使用AutoMapper，但我认为意大利面代码太多。 让我举个例子：

1.）我有一个用户注册过程。我有一个名字，姓氏，电子邮件，OpenId输入映射到ViewModel中相同的 属性。但是，比起我需要不同的实体来存储这些数据（一个用于用户，另一个用于openid身份 - 用户可以具有多个openid身份）。 所以在我的控制器操作中，我有一个视图模型和用户实体之间的映射（AutoMapper）和视图模型和openid实体之间的映射（AutoMapper）。在那之后，我用服务功能保存每个实体 。

我错过了一些东西 - 比如自定义的DTO（我认为viewmodel应该在服务层和web层之间共享），它将在web和服务层之间传递。

2.）我在应用程序中有搜索功能。从控制器操作中，我调用服务层，它返回与搜索条件匹配的文档实体列表。 但问题是我也想显示每个结果的类别（不同的实体）。因此，在控制器操作中，我在结果之间循环，并在视图模型中将类别信息 添加到IDictionary结构中。

我也想念这里的东西 - 又一些DTO，它将返回对（新对象）列表：文档，类别。

DTO是否是正确的模式？我应该看看DDD吗？任何相关的材料将不胜感激。

非常感谢！

Answer 1

我不认为您在应用程序架构中缺少一层，但听起来您缺少某些类型（类）。

您是否应该创建更多的DTO？不，我不认为这是一个好主意。 IIRC，DTO的原始定义是跨越流程边界传输数据。 WCF数据合同是DTO的一个很好的例子。但是，由于DTO仅仅是消息，它们不包含任何行为。如果你在DTO中建立内部API，它将导致Anemic Domain model。

您应该认真考虑在您的应用程序中添加新类型以捕捉您的需求。这种类型应该去哪里？

这取决于。如果可以说所讨论的类型封装了一个通用的概念，它就属于域模型。如果只支持给定的（用户）接口，它就属于该层。

在你的第二个例子中，你需要结合Document和Category，尽管它们是独立的实体。这种组合是否包含一个反复出现的概念？如果是这样，它就属于你的域模型。如果不是，它就属于你的UI层。

如果有疑问，请将新类型放置在外层（您的UI层）。如果事实证明这是一个比您最初想象的更普遍的概念，您可以相对轻松地将其移动到您的领域模型。移动另一种方式更难，因为这种类型可能已经污染了域模型，所以从外层开始是最安全的选择。