I have a basic logical question about Dapper.
In attempting to do best design practices does Dapper blur the line between DAL and BLL? Many recommendations are that the DAL should know nothing about the BLL and that the DAL should just return some blob of data which the BLL should convert into some useful object.
I would like to get the opinion of some of the experts here on where Dapper fits in.
It is a great project, and works very well, but it seems tightly coupled with the BLL. I'm not personally opposed to the approach, but wondered if 1) there was a better way to uncouple Dapper and BLL, or 2) if it is no real problem since we don't plan to go away from MS SQL.
Thanks.
EDIT: in response to Marc's comment:
Dapper is a great product and this is not a slam on it in any way... What I mean by coupled with the BLL is that when you execute a query, it is commonly going to return a collection of a specific type.
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });
In this case the query will return a collection of Dog.
If Dapper was deployed in the DAL layer, it would have to have a reference to the BLL layer in order to know about the types of objects it is going to return.
Many recommendations are that the DAL should never know anything about the BLL. I'm just trying to size up the best practice for deploying Dapper and keeping a good N-Tier design structure.
I know it is somewhat subjective, but if it is good enough to power Stack Overflow, then you all must have figured out the best practice way to deploy it in a well designed environment.
EDIT: Noticed that thetype of "Dog" wasn't shown in the query example due to the HTML symbols.
EDIT again in response to Hogan's comments: The heart of my question is more related to the idea that the line of code above would be in the DAL. For clarity sake, we can assume that we have a solution with the DAL and the BLL as separate class projects. Now, when this line of code goes in the DAL project, the DAL will have to reference the BLL to get the "Dog" object. Is this cross dependency okay? or just the way the Dapper is most commonly used? Or is it a bad practice and just not the best way to use Dapper? I know many 'purists' would say the DAL should not know anything about the BLL... relying on the "Dog" object in the line above would violate that principle. However, the line above seems to be the most common example usage of Dapper.
Think of dapper as a Rack for databases, read: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper
Dapper is not going force you to use repositories or any particular patterns.
It is not going to tell you where to put your business logic. If you want to muddle your business logic with your data access code, so be it. If you do not, don't. Dapper is agnostic. It is a simple data access technology.
We use Dapper in our repository/data layers as a quick and easy way to map our data to our objects without writing extra code to do the mapping. It is up to you whether you want to use DTOs to transfer your data between layers or map directly to your entities (BOs) which can be in a separate common layer.
It all depends on the level of abstraction that you want to implement. If you use Entity Framework and make your LINQ queries directly in your business layer, then you are tightly coupling your logic to EF and your entities are being used in your data and business layer as well.