Repository pattern and Business logic

Question

I have a repository (CustomerRepository) that retrieves data from the data layer. Most of the business logic is in the entity class (Customer) that the repository either accepts or returns.

However, where do you put the global entity business logic (that applies to all customers)?

For instance, I may not want to return all customers to certain users. I don't want to put that logic in the repository.

Answer 1

I agree with Robert Munteanu.

Basically you roll up your business logic that isn't inherent in your model into a middle tier. The middle tier is the business tier / business objects / business logic layer / etc, but is just referred to as a service tier. It doesn't have to be a webservice, its a broad use of the term service in that it aggregates functionality of a specific application area.

You would basically have a CustomerService class that contains the repository reference. Your presentation layer would reference the service layer class.

There is an additional distinction that can be made as a guess from your name you are using .net, and probably using LINQ to SQL as your repository as outlined in NerdDinner.

The Repository typically returns IQueryable to the service layer, allowing the service layer chain together multiple queries to build different result sets. The Service then evaluates the expression using ToList or another similar method and returns that to the presentation layer.

Answer 2

Wrap it behind a service.

Answer 3

Put it in another repository (BusinessRuleRepository) and have CustomerRepository use it.

OR

If the business logic is only limiting the results a user can see you might want to use a Facade pattern with a factory. In this case you would have an ICustomerRepository that handles your CustomerRepository and LimitedCustomerRepository (which might encapsulate CustomerRepository), and a CustomerRepositoryFactory that returns the appropriate ICustomerRepository for the user.

Answer 4

I think separating these types of functions into a service layer is the way to go.

I recently built a system to do complex forecasting with many entities using historical data. Putting all the data access bits in the repository for each entity. The intricate forecasting logic I kept in a service layer and passed the repository objects in as needed.

Added bonus was that I had an easy way to expose all the forecasting logic to external systems by simply creating a web api layer.