I've been working on our application (CQRS and DDD) for awhile now. The application architecture is well layered and thought through.
However we are having difficulties in decide where to put the below code, in such a way that it makes sense from an architectural point of view.
What the code does: It's a generic method which executes a query against the dataset, specified by the generic parameter which inherits a particular interface. Note: we are not using repositories, since the query is, as the name indicates, for our read layer.
The interface, used by the generic method:
public interface IOrganisationalDbEntry
{
string OrganisationLevelId { get; set; }
OrganisationLevelDbEntry OrganisationLevel { get; set; }
}
The generic method, which lives inside our Entity Framework DbContext:
public IList<TDbEntry> GetByOrganisationLevel<TDbEntry>(Guid? organisationLevelId,
Func<TDbEntry, bool> filter = null)
where TDbEntry : class, IOrganisationalDbEntry
{
var organisationLevel = organisationLevelId.HasValue ? organisationLevelId.Value.ToString() : null;
var query = filter == null ? Set<TDbEntry>() : Set<TDbEntry>().Where(filter);
IList<TDbEntry> result = query.Where(x => x.OrganisationLevelId == organisationLevel).ToList();
// If there are no results for the current organisation level
// => recursive check for entries for parent organisation level
if (!result.Any() && !string.IsNullOrWhiteSpace(organisationLevel))
{
// Get parentOrganisationLevel
var parentOrganisationLevelId = Set<OrganisationLevelDbEntry>()
.Where(x => x.Id == organisationLevel)
.Select(x => x.ParentOrganisationLevelId)
.SingleOrDefault();
return
GetByOrganisationLevel<TDbEntry>(
string.IsNullOrWhiteSpace(parentOrganisationLevelId)
? (Guid?)null
: new Guid(parentOrganisationLevelId), filter);
}
return result;
}
As you may be thinking, we have several EF Entities inheriting the IOrganisationalDbEntry
. What comes to mind first, is a base Repository. But We do not want to use repositories in our query side, since we want this layer to be as flat as possible.
The next thing that comes to mind is a specific query and queryhandler for this query. Tho this is not acceptable since this method accepts a Func parameter to be able to add extra filter criteria while calling this method, to make it more flexible.
At this moment, this method is living as method on our IDbContext and DbContext implementation. However we are not satisfied with this. We are wondering whether there is a specific pattern or approach for our case. Imagine we have more of these methods, I do not want to keep expanding our context. Since this is not what the DbContext
should be used for.
IEnumerable<>
instead ofIList<>
since you probably won't add/remove items of the result of the query – TopinFrassi Aug 19 '14 at 14:19