Automapper与Dapper进行映射 [英] Automapper vs Dapper for mapping

问题描述

这个问题是要验证当前的实施是否是最佳实践和性能方面的正确方法.到目前为止，在我以前的所有公司中，我一直在使用Auto Mapper将关系对象映射到域模型实体，将域模型实体映射到Dtos. ORM工具已经是实体框架. 在我目前的公司中，他们使用Dapper作为ORM工具，而不使用AutoMapper，因为他们说Dapper在内部为您执行映射.因此，他们构建项目的方式是创建一个单独的类库项目，其中包含Dtos并在Dataccess和Business层中引用Dtos. Dapper返回的查询在内部映射到Dto.这些Dto返回到业务层，依此类推.

This question is to verify if the current implementation is the right way to go about in terms of best practices and performance. So far in all my previous companies I have been using Auto Mapper to map relational objects to domain model entities and domain model entities to Dtos. The ORM tools have been Entity framework. In my current company they are using Dapper as ORM tool and do not use AutoMapper as they say Dapper does the mapping for you internally. So the way they have structured the project is create a separate class library project that contains Dtos and reference the Dtos in Dataccess and Business layer. The query returned by Dapper is internally mapped to the Dtos. These Dtos are returned to the Business layer and so on.

例如

在Participant函数下面的代码中是Dto.

In the code below the Participant function is Dto.

DataAccess层中的存储库文件

 public List<ParticipantFunction> GetParticipantFunctions(int workflowId)
        {
            // Update the Action for Participant
            string selectSql = @"SELECT [WFPatFunc_ID] AS WFPatFuncID
                        ,[WFFunction]
                        ,[SubIndustryID]
                        ,[DepartmentID]
                    FROM [dbo].[WF_ParticipantsFunctions]
                    WHERE [DepartmentID] = (SELECT TOP 1 [DepartmentID] FROM [dbo].[WF] WHERE [WF_ID] = @workflowId)";

            return _unitOfWork.GetConnection().Query<ParticipantFunction>(selectSql, new
            {
                workflowId = workflowId
            }).ToList();
        }

开发人员告诉我的原因是AutoMapper只是一项开销，会降低速度，并且由于Dapper确实在内部进行映射，因此不需要它.

The reason what I have been told by the developers is that AutoMapper would be just an overhead and reduce speed and since Dapper does mapping internally, there is no need for it.

我想知道他们遵循的做法是否很好并且没有问题.

I would like to know if the practice they are following is fine and have no issues.

推荐答案

此处 没错.如果当前系统可以正常工作并解决了所有要求，那就太好了:使用它！如果您对自动映射有用的东西有实际需求，那就太好了:使用它！

There is no right or wrong here. If the current system works and solves all their requirements, then great: use that! If you have an actual need for something where auto-mapper would be useful, then great: use that!

但是:如果您不需要需要自动映射器可以完成的事情(并且看来它们不需要)，那么...就可以不使用它吗?

But: if you don't have a need for the thing that auto-mapper does (and it appears that they do not), then... don't use that?

也许一个关键点/问题是:如果您的需求在以后发生变化，那么您重构代码的能力是什么?对于许多人来说，答案是确定，我们可以更改内容"-因此，在这种情况下，我会说:推迟添加额外的层，直到您真正需要额外的层为止.

Perhaps one key point / question is: what is your ability to refactor the code if your requirements change later. For many people, the answer there is "sure, we can change stuff" - so in that case I would say: defer on adding an additional layer until you actually have a requirement for an additional layer.

如果您绝对不会以后能够更改代码，也许是由于许多面向公众的API(作为产品的软件)，那么取消所有的耦合是有意义的> now ，因此公共API中没有耦合/依赖关系.但是:大多数人没有.除此之外，dapper对您的类型模型没有任何要求，除了:它必须看起来像表.如果这样做的话，那么再说一遍:为什么在不需要时再添加一个额外的图层?

If you will absolutely not be able to change the code later, perhaps due to lots of public-facing APIs (software as a product), then it makes sense to de-couple everything now so there is no coupling / dependency in the public API. But: most people don't have that. Besides which, dapper makes no demands on your type model whatseover other than: it must look kinda like the tables. If it does that, then again: why add an additional layer if you don't need it?

这篇关于Automapper与Dapper进行映射的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！