这个问题是为了验证当前的实现是否是最佳实践和性能方面的正确方法。到目前为止，在我以前的所有公司中，我一直在使用 Auto Mapper 将关系对象映射到域模型实体，并将域模型实体映射到 Dtos。 ORM 工具已经成为 Entity 框架。 在我目前的公司中，他们使用 Dapper 作为 ORM 工具，而不使用 AutoMapper，因为他们说 Dapper 在内部为您进行映射。因此，他们构建项目的方式是创建一个单独的类库项目，其中包含 Dtos 并在数据访问和业务层中引用 Dtos。 Dapper 返回的查询在内部映射到 Dtos。这些Dto返回给Business层等等。
例如
在下面的代码中，Participant 函数是 Dto。
数据访问层的存储库文件
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 在内部进行映射，因此不需要它。
我想知道他们遵循的做法是否正常并且没有问题。
最佳答案
这里没有对错之分。如果当前系统有效并解决了他们的所有需求，那就太好了:使用它!如果您实际需要自动映射器有用的东西，那就太好了:使用它!
但是:如果您不需要自动映射器所做的事情(而且看起来他们不需要)，那么...不要使用它？
也许一个关键点/问题是:如果您的需求稍后发生变化，您重构代码的能力如何。对于许多人来说，答案是“当然，我们可以改变一些东西”——所以在这种情况下我会说:推迟添加一个额外的层，直到你确实需要一个额外的层。
如果您以后绝对不能更改代码，可能是因为有很多面向公众的 API(软件即产品)，那么解耦所有东西是有意义的现在 所以在公共(public) API 中没有耦合/依赖。但是:大多数人没有。除此之外，dapper 对您的类型模型没有任何要求，除了:它必须看起来有点像表格。如果它这样做了，那么再说一遍:如果你不需要它，为什么要添加一个额外的层？
关于c# - 用于映射的 Automapper 与 Dapper，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44775320/