我有一个关于Dapper的基本逻辑问题.
在尝试做最好的设计实践时,Dapper是否模糊了DAL和BLL之间的界限？许多建议是DAL应该对BLL一无所知,并且DAL应该只返回BLL应该转换为某些有用对象的一些blob数据.
我想在这里得到一些专家对Dapper适合的意见.
这是一个伟大的项目,并且运作良好,但它似乎与BLL紧密结合.我个人并不反对这种方法,但是想知道1)是否有更好的方法可以解开Dapper和BLL,或2)如果它不是真正的问题,因为我们不打算离开MS SQL.
谢谢.
编辑:回应马克的评论:
Dapper是一个很棒的产品,这不是对它的任何影响......我的意思是,当你执行一个查询时,它通常会返回一个特定类型的集合.
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"的类型.
再次编辑以响应Hogan的评论:我的问题的核心与上面的代码行将在DAL中的想法更相关.为清楚起见,我们可以假设我们有一个DAL和BLL作为单独的类项目的解决方案.现在,当这行代码进入DAL项目时,DAL必须引用BLL来获取"Dog"对象.这种交叉依赖性可以吗？或者只是最常用的Dapper？或者这是一种不好的做法,而不是使用Dapper的最佳方式？我知道很多'纯粹主义者'会说DAL不应该知道关于BLL的任何事情......依赖于上面一行中的"Dog"对象会违反这个原则.但是,上面的行似乎是Dapper最常见的示例用法.