Question

I’m currently building a framework that uses a MySQL database. I can’t use the MySQL implementation of the entity framework, so I’m trying to figure out the best way of generalising search and paging functionality.

The simplest solution would be to have repository methods with signatures such as:

IList<Blah> GetSomething(string _query, 
                         int _page, 
                         int _pageSize, 
                         out int _numPages)

but this seems slightly anti-OOD.

An idea I had was to create a utility dll with an ISearchParameter and an IPaging object that both the domain level and repository level could access, this would avoid having to recreate these two interfaces and implimentations of them in each domain and repository.

public interface ISearchParameters
{
    Direction Direction { get; set; }
    string DirectionField { get; set; }
    string Query { get; set; }
    IList<string> SearchFields { get; set; }
}

public interface IPaging
{
    int CurrentPage { get; set; }
    int PageSize { get; set; }
    int NumberOfPages { get; set; }

    int GetQueryPage();
}

I’d usually map DTOs from the repositories to domain objects, but if both levels referenced this utility .dll, would it be bad design to pass ISearchParameter objects between these two levels without mapping? If so, are there any better solutions?

Answer 1

1. Use the Repository Pattern to abstract away your interaction with data access layer.
2. Use an Inversion of Control container to create your repository, to avoid a reference from your domain to data access layer.
3. The data access can then hold a reference to your domain classes, or to the domain class factories–avoiding the need for DTOs (following the DRY principle).
4. Design your interfaces to be stateless. When crossing layers (which may become tiers), think of services instead of objects. This would prefer the simpler approach.
5. Avoid having a utility.dll. You really only need to share your repository interfaces between your domain and data access layer. You could put those in your domain assembly, or better, a separate assembly.