views:

57

answers:

1

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  A: 

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.

Oded
+1 Actually in Smart client applications you can also have client side repository ...
Ladislav Mrnka
So I should transfer data like thisentity framework entities <-> DTO's <-> Business layer entities?It looks like a lot of overhead to me, especially because all that the DTO's do is move data between layers.
scripni
@scripni - That is the purpose of the DTO, correct. A lot of overhead? Possibly. But you gain clarity, you don't pass in behavior and have objects with clear concerns.
Oded