AutoMapper(4.2+)Profile是逻辑还是基础设施的一部分?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了AutoMapper(4.2+)Profile是逻辑还是基础设施的一部分?相关的知识,希望对你有一定的参考价值。
我有WCF服务,就像ORM一样。我需要一个映射器将实体映射到Dtos。考虑到关注点,SOLID和DDD的分离,我想知道AutoMapper配置和配置文件应该去哪里?我的项目结构如下:
数据(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服务中。但我有点困惑,因为我的Windows服务项目没有“数据”引用(与实体)。所以我有几个问题:
- 我应该在WindowsService(主机)中添加对“Data”项目的引用,并在WindowsService中创建AutoMapper Profile类吗?
- 我应该在Logic类中定义AutoMapper Profile类(它知道Dtos和Entities),然后在WindowsService中引用Logic来初始化模块吗?
- 我应该将AutoMapper Profile放在其他地方吗?
谢谢!
使用Java,使用此结构
数据(EF) - >逻辑 - > WCF服务/ WCF合同 - > WindowsService(主机)
我认为是一组不同的包/项目。那么每个包/项目(按我的解释):
- 数据(EF):实体到持久性的映射,知道如何获取实体并将其转换为Dto(这里我将把配置/逻辑告诉AutoMapper如何转换对象)
- 逻辑:域的逻辑在哪里,应该是架构的核心,它应该(必须,我会说)不知道其他包/项目
- WCF服务/ WCF合同:一组公开功能的接口
- WindowsService(主机):接口的实现,因此其他包/项目之间的粘合代码所在。例如,在这里我将放置AutoMapper的配置文件。
WindowsService(主机)是一种基础结构层,所有内容都放在一起。在这里,您需要参考您将要使用的每个包/项目(数据,逻辑,WCF服务/ WCF合同)。
将配置文件放在Logic中,因为这是您可以设置的最上游点,即Logic具有映射的两个方面(实体和Dtos)。如果你想让Logic保持美观,就像@Luca建议那么你可能想要考虑将你的Dtos移动到你的WCF层(以及Profiles)。
您的Windows服务肯定已经引用了这个逻辑。
这样,可能使用此逻辑的其他项目(可能是Web应用程序)也可以使用该配置文件。
以上是关于AutoMapper(4.2+)Profile是逻辑还是基础设施的一部分?的主要内容,如果未能解决你的问题,请参考以下文章