AutoMapper (4.2+) Profile 是逻辑还是基础架构的一部分？答案

【问题标题】：Is AutoMapper's (4.2+) Profile part of Logic or Infrastructure?AutoMapper (4.2+) Profile 是逻辑还是基础架构的一部分？
【发布时间】：2018-03-06 05:47:34
【问题描述】：

我有 WCF 服务，其作用类似于 ORM。我需要一个映射器将实体映射到 Dtos。考虑到关注点分离、SOLID和DDD，我想知道AutoMapper配置和Profiles应该去哪里？我的项目结构是这样的：

数据 (EF) -> 逻辑 -> WCF 服务/WCF 合同 -> WindowsService（主机）

我遵循 github 的规则，创建了一个 Ninject 模块：

public class AutoMapperModule : NinjectModule
{
    public override void Load()
    {
        Bind<IValueResolver<SourceEntity, DestModel, bool>>().To<MyResolver>();

        var mapperConfiguration = CreateConfiguration();
        Bind<MapperConfiguration>().ToConstant(mapperConfiguration).InSingletonScope();

        // This teaches Ninject how to create automapper instances say if for instance
        // MyResolver has a constructor with a parameter that needs to be injected
        Bind<IMapper>().ToMethod(ctx =>
             new Mapper(mapperConfiguration, type => ctx.Kernel.Get(type)));
    }

    private MapperConfiguration CreateConfiguration()
    {
        var config = new MapperConfiguration(cfg =>
        {
            cfg.AddProfiles(new SampleProfile());
        });

        return config;
    }
}

public class SampleProfile : Profile
{
    public SomeProfile()
    {
        CreateMap<Foo, FooDto>();
    }
}

我总是在可执行程序的入口处创建一个Ninject模块，所以在Windows Service中。但我有点困惑，因为我的 Windows 服务项目没有“数据”引用（带有实体）。所以我有几个问题：

是否应该在 WindowsService（主机）中添加对“Data”项目的引用并在 WindowsService 中创建 AutoMapper Profile 类？
是否应该在 Logic 类（知道 Dtos 和 Entities）中定义 AutoMapper Profile 类，然后在将初始化模块的 WindowsService 中引用 Logic？
我应该将 AutoMapper 配置文件放在其他地方吗？

谢谢！

【问题讨论】：

当然是基础设施。任何执行非常特定部分的第 3 部分库都是基础架构，包括但不限于：ORM、数据库提供程序、UI（MVC、WebForms）、端点（WCF、WebAPI）、身份验证、Xslt 处理器、服务/消息总线（实现）、本地和分布式缓存、Swagger，当然还有 AutoMapper。另外请记住，IoC 容器（因为您提到使用 ninject 模式）也是基础架构，因为它们是可替换的，而不是您的域/业务逻辑的重要组成部分

标签： c# wcf domain-driven-design automapper ninject

【解决方案1】：

使用这种结构的 Java

数据 (EF) -> 逻辑 -> WCF 服务/WCF 合同 -> WindowsService（主机）

我认为是一组不同的包/项目。然后每个包/项目都是（在我的解释中）：

数据 (EF)：实体到持久性的映射，知道如何获取实体并将其转换为 Dto（我将在这里放置告诉 AutoMapper 如何转换对象的配置/逻辑）
逻辑：域的逻辑在哪里，应该是架构的核心，它应该（我会说必须）不知道其他包/项目
WCF 服务/WCF 合同：一组公开功能的接口
WindowsService（主机）：接口的实现，因此是其他包/项目之间的粘合代码所在。例如，在这里我会放置 AutoMapper 的配置文件。

WindowsService (host) 是一种基础设施层，所有的东西都放在一起。在这里，您需要引用您将要使用的每个包/项目（数据、逻辑、WCF 服务/WCF 合同）。

【讨论】：

hmm.. 你说过Data - “我会在这里放置告诉 AutoMapper 如何转换对象的配置/逻辑”。然后关于 WindowsService （主机），您说：“我将把 AutoMapper 的配置文件放在这里。”。那么..在哪里？
对不起，我不习惯 AutoMapper。我认为配置和配置文件是分开的并且彼此独立（对您所写内容的错误解释）。鉴于这不是真的，即使您可以在data 和WindowsService (host) 之间进行选择，我也会建议第二个。通过这种方式，基础设施代码（胶水代码）保留在一个明确定义的位置。

【解决方案2】：

将配置文件放在 Logic 中，因为这是您可以放在上游的最远点，即 Logic 具有映射的两侧（实体和 Dtos）。如果您想像@Luca 建议的那样保持逻辑的美观整洁，那么您可能需要考虑将您的 Dtos 移动到您的 WCF 层（连同配置文件）。

您的 Windows 服务肯定已经引用了这个逻辑。

这样，可能使用此逻辑的其他项目（可能是 Web 应用程序）也可以使用配置文件。

【讨论】：