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

Question

我有一个三层的 asp.net mvc 应用程序： - 具有实体和存储库（休眠）模式的数据层 - 具有服务（功能）的服务层，它与数据层通信。 - 带有 asp.net mvc 应用程序的 ui 层，它与服务层通信。

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

1.) 我正在进行用户注册过程。我有一个 FirstName、LastName、Email、OpenId 输入，它们映射到相同的 ViewModel 中的属性。但是，我必须使用不同的实体来存储这些数据（一个用于用户，一个用于 openid 身份 - 用户可以拥有多个 openid 身份）。 因此，在我的控制器操作中，我在视图模型和用户实体之间有一个映射（AutoMapper），在视图模型和一个 openid 实体之间有一个映射（AutoMapper）。在那之后 我用服务函数保存每个实体。

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

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

我在这里也错过了一些东西 - 再次是一些 DTO，它将返回对列表（新对象）：文档、类别。

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

非常感谢！

Answer 1

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

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

您仍应认真考虑向您的应用程序添加新类型以满足您的需求。这些类型应该去哪里？

这取决于。如果您可以说所讨论的类型封装了一个通用的概念，那么它属于一个领域模型。如果它只是为了支持给定的（用户）界面而存在，则它属于该层。

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

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