Question
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.
Accepted Answer
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.
Popular Answer
I think your question is ignoring context. DAL and BLL are often about context. It is not about a single line of code (as your question suggests) but about the class, the namespace and even the path in a project to the source file with the line code. Many times these issues are ignored by programmers who want to write a good DAL and BLL and think that if they use the right tool the problem is instantly solved.
Let me give you some examples based on the line of code you've provided above to make my point clear.
If I was reading the source code for a project and found that line of code in a *.aspx.cs file I would be a little distressed. The project is not n-tier or modular.
Conversely, if I was reading the source and found that line of code in a file called dog.cs in the DAL sub-directory of a project it would be clear this code is intended to act as data access for dog objects in the solution.
A similar conclusion can be drawn if the it was located in a directory call BLL.
Don't miss understand my point -- I'm not suggesting you HAVE to have a directories name DAL and BLL in your solution -- I'm just saying that what defines these elements is external to a section of code that performs data access. Such a line of code could contribute to a nicely designed n-tier system or detract from it.