In which layer should i put my repository?

7
votes

Scenario

Data Access Layer

  • EF's generated .edmx and classes
  • Used only to access the SQL Database and pass the data forward to the business layer

Business Layer

  • Business entities : contain all validation logic, marked with the [DataContract] attribute so that they can be passed as parameters to my web service

Problem

I want to use the repository pattern with this approach. The repository would contain all CRUD operations to be performed on the database, accepting and returning business layer entities. This means that the repository will reside in the business layer, because only the business layer can reference the data layer, not the other way round. I'm also planning to use the data layer assembly in other projects, that's why I would like to have the repository in the data layer, not the business layer (which is particular for this project).
What do you recommend? Should I keep the repository in the business layer and write one for each different business layer? Or should I keep the repository inside the data layer, not accepting or returning business entities.
Or, as an alternative, can anyone recommend a different approach, that would yield a more logical, scalable architecture?

Thanks for reading, waiting for answers

3
c#design-patternsrepository
That's exactly the same question I have. I'm thinking about separating my business entities in a new DataContracts assembly. Thus, both the Business Layer and Data Layer would reference this DataContracts. – digaomatias

3 Answers

9
votes

A repository is an abstraction over the data layer - to afford persistence ignorance to your application. It should only deal with data access and nothing more. It should not have any business logic.

The repository can and should accept and return DTOs (Data Transfer Objects) - these are simple objects that do not have behavior of their own and are used to transfer data between layers.

I would put it between the DAL and the BLL and only use it for data access from the BLL.

4
votes

I like the accepted answer. Ideally, having a completely layer dedicated to the Repositories sounds right.

But I think, in a traditional 3-tier only application (e.g. "Data->Business->UI"), I would stick the Repositories in the Data layer. The reason I would put them in the Data Layer, is because they deal strictly with data access. The reason I would NOT put them in the Business Layer, is because they should NOT have any business logic to them.

1
votes

I think repository interface should be in business layer, but implementation of this interface should be in data layer. Interface enable unit testing, but repository implementation is not responsibility of business layer.