从控制器（表示层）内映射域实体是否正确？答案

【问题标题】：Is it correct to map a domain entity from within the controller (presentation layer)?从控制器（表示层）内映射域实体是否正确？
【发布时间】：2016-03-04 12:31:52
【问题描述】：

我在 Visual Studio 2015 中有一个解决方案，我将 DDD 层分离为项目。当我需要将数据从表示层（MVC 5）发送到应用层（类库）时，我通常使用：

应用服务

public interface IFooAppService
{
    void AddNew(string name, DateTime birthday);
}

控制器

[HttpPost]
public JsonResult AddNew(FooViewModel viewModel)
{
    FooAppService.AddNew(viewModel.Name, viewModel.birthday);
}

当我有一个具有许多属性和子实体的域实体类时，应用程序服务方法签名变得太长。考虑到 DDD 和关注点分离，在这种情况下，将 FooViewModel 类直接从 MVC 控制器映射到 Foo 域实体是否正确？这样的实现将是：

应用服务

public interface IFooAppService
{
    void AddNew(Foo foo);
}

控制器

[HttpPost]
public JsonResult AddNew(FooViewModel viewModel)
{
    Foo foo = FooMapper.Map(viewModel);
    FooAppService.AddNew(Foo);
}

【问题讨论】：

我认为这取决于对象。如果域模型完全反映了您的视图模型，那么它就没有问题。无论哪种方式，转型都需要发生。但我不会为了使映射工作而将不必要的域实现引入视图模型。
对于任何对此投反对票的人，请分享您对如何改进它的想法，以便我可以修复它。到目前为止，我认为这是我和其他人将来可能会担心的问题。
一般情况下，我通过将所需数据封装到类似 dto 的值对象中来避免大型方法签名，并遵循汇编模式进行映射。我的大多数解决方案在各种表示层和我的服务之间都有一个网络边界，所以效果很好。
控制器负责视图和域之间的连接。拥有该领域的知识是完全合理的。为了抽象而抽象是愚蠢的。
总的来说，我同意 Chris 的观点（尤其是他所说的抽象）。对于大多数应用程序和情况，这样做很好。这取决于 MVC 事务中存在什么样的边界（因为 MVC 模式本身不仅仅是服务器到客户端的 UI 模式）。具有显着规模/规模的 DDD 系统必须容纳的不仅仅是将数据从服务器移动到 UI 客户端。

标签： c# asp.net-mvc domain-driven-design separation-of-concerns

【解决方案1】：

将FooViewModel类映射到Foo域实体是否正确在这种情况下直接来自 MVC 控制器？

如果您有应用服务，我会拒绝。您为创建一个额外的应用程序层而烦恼，以便表示层可以专注于做 UI 工作，而不是直接处理域。仅仅因为“方法签名太长”而想要将其短路似乎很奇怪。

此外，来自 CQ(R)S 的 Command 概念可以帮助您解决该参数问题。控制器可以调用应用程序服务，只传递一个命令。

【讨论】：

【解决方案2】：

如果您拥有的是从 DTO 到实体的简单映射，那么您可能正在构建一个 anemic domain model。

您应该尝试使用 DDD 构建成熟的域模型，或者求助于 CRUD 样式的应用程序。根据应用程序的性质，它们都是有用的。 DDD 通常只对复杂的问题域有意义。

【讨论】：