2

I usually define my repository interfaces at Domain Layer with DDD. Given that the UI needs to display some paged data I thought that adding params such as currentPage, pageSize, and define a model PagingResult at my domain layer have not to do with domain itself.

This is the method signature:

PagingResult<Customer> GetCustomers(int currentPage, int pageSize, string nameToFind);

Should I keep this method at my domain ICustomerRepository? I thought about define it on application layer within a new ICustomerAppRepository.

So basically the question is: is it fine or common to have this kind of method on domain repositories interfaces?

4
  • "Is it fine or common to have this kind of method.... " Can you tell me what you mean by "fine" and "this kind of" in this sentence?
    – John Wu
    Commented Dec 7, 2018 at 19:18
  • I mean not an anti-pattern....
    – Murilo
    Commented Dec 7, 2018 at 19:26
  • And "this kind of" ...? What is it you believe is different about this method compared to other methods?
    – John Wu
    Commented Dec 7, 2018 at 19:26
  • A method with UI/application-related concept(page-size, current page) within domain
    – Murilo
    Commented Dec 7, 2018 at 19:28

1 Answer 1

1

Sometimes you just need to support pagination at the database layer, for performance reasons. It's not a violation of separation of concerns if you conceptualize pagination in an application-agnostic way.

So for example instead of

PagingResult<Customer> GetCustomers(int currentPage, int pageSize, string nameToFind);

You could write

IEnumerable<Customer> GetCustomers(string nameToFind, int numberToReturn);

and

IEnumerable<Customer> GetCustomers(
    string nameToFind, 
    int numberToReturn, 
    Customer startAfter
);

You could then use the first method above to get the first set of results and use the second method to get subsequent result sets starting with the first customer after the last row of the previous page.

This removes the concept of pagination from the data layer but still gives you the methods you need to obtain the records for the UI.

2
  • This is way over complicating a concept for the sake of design philosophy. Paging through a result set is so common it's something you just build in to the infrastructure of the application, and not worry about "polluting" a repository interface. There's nothing wrong with pagination info here. Even if you throw another UI on the application, I'd bet good money they want pagination. You can always provide an overload that doesn't include pagination if need be, but jumping through this many hoops to avoid it is just plain silly. Commented Dec 9, 2018 at 0:05
  • 1
    Um...? This isn't complicated, and I'm not a philosopher. The data layer implementation will actually be far simpler, and this approach simplifies the dependency graph, removes the need for synchronized deployment if the pagination logic changes, and improves data integrity without requiring statefulness on the data layer (otherwise you could get duplicated or missing rows in the presence of concurrency). This is actually a very pragmatic solution. In a modern web app, pagination logic and data caching will probably happen on the client browser anyway.
    – John Wu
    Commented Dec 11, 2018 at 4:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.