Question

If you have a business rule where the first 30 items in table will never be seen by the user (or UI) should you put this filter in the Repository’s GetAll()? Meaning, would the repository handle filtering of data, molding of data to hand back to the caller like a ViewModel or Controller? I’ve heard that Models should be thick, and controllers/vms should be light.

The issue I’m running into is another developer who is sharing a project with me made all of his repositories (one per table) simply all use the same implementation that simply copies properties of a LinqToSql type to a domain type. There’s no logic in the repository itself other than updating and deleting or getting data by a Func supplied.

I on the other hand created a repository (that inherited from IRepository of T) for each table and put specific logic in some (not all) where I felt logic was needed to hand back the domain objects.

So in my case, business logic could be done in the repository, in his case it has to be done by the user which could be a service or the ViewModel directly. Which is more preferred?

Answer 1

If you have a business rule where the first 30 items in table will never be seen by the user (or UI) should you put this filter in the Repository’s GetAll()?

First of all this does not sound like a business rule. Business rules are expressed in ubiquitous language and this language does not have words like ‘table’ unless you are working on a database engine.

Answering you main question, the filtering logic can absolutely live inside repository. This is what repository is for: encapsulate storage, retrieval and search. One of the most important things to understand about repository is that its interface belongs to domain layer, but its implementation belongs to data access layer. So in your case the code would look like this:

Domain:

// repository interface:
public interface Orders{ 
   IList<Order> GetDelinquent();
}

Data access:

public SqlOrders : Orders{ 
   IList<Order> GetDelinquent(){
      // do whatever needs to be done to find
      // delinquent orders in sql database.
      // filter first 30 records for example
   }
}

Note that repository interface brings domain into focus (we don’t say ‘all but first 30 records‘, we say ‘delinquent‘).

The issue I’m running into is another developer who is sharing a project with me made all of his repositories (one per table) simply all use the same implementation that simply copies properties of a LinqToSql type to a domain type. There’s no logic in the repository itself other than updating and deleting or getting data by a Func supplied.

I on the other hand created a repository (that inherited from IRepository of T) for each table and put specific logic in some (not all) where I felt logic was needed to hand back the domain objects.

Generic repository interface is usually a bad idea, it is too data-centric, too CRUDy, please see this answer for details and links.

So in my case, business logic could be done in the repository, in his case it has to be done by the user which could be a service or the ViewModel directly. Which is more preferred?

There is a big difference between business logic and data access logic. You want to avoid putting business logic into repository implementation. This logic belongs to domain objects.