与n层设计（BLL / DAL）相关的小巧玲珑

Question

我有一个关于Dapper的基本逻辑问题。

在尝试做最好的设计实践时，Dapper是否模糊了DAL和BLL之间的界限？ 许多建议是DAL应该对BLL一无所知，并且DAL应该只返回一些BLL应该转换成一些有用对象的数据。

我想得到一些专家对Dapper适合的意见。

这是一个伟大的项目，并且运作良好，但它似乎与BLL紧密结合。 我个人并不反对这种方法，但是想知道1）是否有更好的方法来解开Dapper和BLL，或2）如果它不是真正的问题，因为我们不打算离开MS SQL。

感谢。

编辑：回应马克的评论：

Dapper是一个很棒的产品，这不是对它的任何影响...... 与BLL结合使用的意思是，当您执行查询时，通常会返回特定类型的集合。

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

在这种情况下，查询将返回Dog的集合。

如果Dapper部署在DAL层中，则必须具有对BLL层的引用，以便了解它将返回的对象类型。

许多建议是DAL永远不会对BLL有任何了解。我只是试图确定部署Dapper和保持良好的N层设计结构的最佳实践。

我知道这有点主观，但如果它足以支持Stack Overflow，那么你们都必须找到在设计良好的环境中部署它的最佳实践方法。

编辑：注意到由于HTML符号，查询示例中未显示“Dog”的类型。

再次编辑以回应霍根的评论： 我的问题的核心与上面的代码行在DAL中的想法更相关。为清楚起见，我们可以假设我们有一个DAL和BLL作为单独的类项目的解决方案。现在，当这行代码进入DAL项目时，DAL必须引用BLL来获取“Dog”对象。这种交叉依赖性可以吗？或者只是最常用的Dapper？或者这是一种不好的做法，而不是使用Dapper的最佳方式？ 我知道很多'纯粹主义者'会说DAL不应该知道关于BLL的任何事情......依赖于上面一行中的“Dog”对象会违反这个原则。但是，上面的行似乎是Dapper最常见的示例用法。

Answer 1

将dapper视为数据库的Rack，请阅读：http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper不会强迫您使用存储库或任何特定模式。

它不会告诉你在哪里放置业务逻辑。如果您想使用数据访问代码混淆业务逻辑，那就这样吧。如果你不这样做，不要。小巧玲珑是不可知论者。它是一种简单的数据访问技术。

Answer 2

我认为你的问题是忽视背景。 DAL和BLL通常与上下文有关。它不是关于单行代码（如您的问题所示），而是关于类，命名空间甚至项目中包含行代码的源文件的路径。很多时候，想要编写好DAL和BLL的程序员会忽略这些问题，并认为如果他们使用正确的工具，问题就会立即得到解决。

让我根据你上面提供的代码行给你一些例子，以明确我的观点。

如果我正在阅读项目的源代码并发现* .aspx.cs文件中的代码行，我会有点心疼。该项目不是n层或模块化的。

相反，如果我正在阅读源代码并在项目的DAL子目录中名为dog.cs的文件中找到该代码行，那么很明显，此代码旨在充当狗对象的数据访问权限。解决方案。

如果它位于目录调用BLL中，则可以得出类似的结论。

不要错过理解我的观点 - 我并不是建议您在解决方案中有一个目录名称DAL和BLL - 我只是说定义这些元素的内容是一段代码的外部执行数据访问。这样的代码行可能有助于设计良好的n层系统或减损它。

Answer 3

我们在存储库/数据层中使用Dapper作为一种快速简便的方法，可以将数据映射到对象，而无需编写额外的代码来进行映射。是否要使用DTO在层之间传输数据或直接映射到可以位于单独公共层中的实体（BO），由您决定。

这一切都取决于您想要实现的抽象级别。如果您使用Entity Framework并直接在业务层中进行LINQ查询，那么您将逻辑紧密地耦合到EF，并且您的实体也在您的数据和业务层中使用。

Answer 4

关于DAL / BLL的实现，BLL是应该消耗DAL的一种。最健康的事情是在一个独立项目中拥有一个实体层。