[Edit] Looks like this came down to me misunderstaning what Ayende was trying to say, originally... I think it is only a semantic difference between what I stated and what he stated. My oppologies to Ayende for the misunderstanding on my part. [/Edit]
...
Ayende Makes The Statement that Querying Is A Business Concern. I have often made this same statement in the past. My current object model actually has the data access methods all wrapped up in calls via the business logic layer. However, in recent months I have come to disagree with that statement, on a semantic level, though our implementation may be close to the same.
I now believe that the process of needing and using the information provided is a business concern, but the actual implementation mechanics (the query) are a service layer concern.
...
Take the same example that Ayende created, let's talk about a security and permissions system. I like the diagram and general code layout that Ayende provided - it's a good example to work with.
Quoting from his post:
Given a user, I need to find out whatever is has a particular operation with a particular permission. The permissions enum is a bit flag enumeration, with the usual suspects in increasing order (1,2,4,8).
In this scenario, we know that the business need is to provide security and give us a boolean "HasPermission". Ayende directly states that the query is part of the business concern and has the following code directly in a AuthorizationService method:
bool hasPermission =
user.Groups.Exists(grp => grp.Roles
.Exists(role => role.Operations
.Exists(op => op.Permissions == requiredPermission)));
[stated at bottom of post] This query is sitting on an AuthorizationService, and I consider it a 100% business logic.
In my mind, the implementation is almost correct, but not quite. The one part that is missing is an IAuthorizationService interface, to provide a direct distinction between the Interface and it's Implementation.
public interface IAuthorizationService
{
public bool HasPermission();
}
public class AuthorizationService: IAuthorizationService
{
public bool HasPermission()
{
bool hasPermission =
user.Groups.Exists(grp => grp.Roles
.Exists(role => role.Operations
.Exists(op => op.Permissions == requiredPermission)));
return hasPermission;
}
}
Ayende's implementation is only slightly different than mine - I have an explicit interface defined where he is joining the Interface and Implementation in the class definition. However, I see several benefits to the explicit interface declaration, including:
- Ability to Unit Test a process that requires authorization, without actually having the real authorization store available (Mocking the AuthorizationService)
- Loose Coupling and High Encapsulation - explicitly separating the interface from the implementation
- Ability to change the real datastore without affecting the rest of the system (e.g. Ayende's first example is using DLINQ, and his second example is using HQL)
The significant difference may only be semantics, but I think that it is an important distinction to make. The process of knowing the information and using the information is 100% business concern, however, the mechanics of retreiving that information is an implementation concern, not a business concern.