Returning Custom Models from LINQ queries, using Repository and Unit of Work with Entity Framework

Question

I have implemented Repository + UnitOfWork pattern in my DAL, I am using Entity Framework (EF) to connect to the DB.

The service layer calls UnitOfWork to get a specific repository, and then interacts with repository methods using EF Entities.

The returned EF Entities from Repository to Service, are then mapped into Models (POCO objects, only properties, no functionality), and then these POCOs are passed to the Controller that called the Service in the first place.

All looks good so far, except when:

I need to use "Joins" in my LINQ queries in my repository, and return a custom object to the service layer.

The problem here is, that I was making sure, my repository only takes in and sends out EF Entities. But if I need to use join, I'll be populating a custom Model object, and will then be passing back Model instead of EF Entity.

To tackle the above problem, I was thinking that I should change my repository such that, it takes IN entities (e.g. for ADD, DELETE, UPDATE), but returns back Models (for select methods etc).

This means, my service layer will be creating Entities from Models, and then passing entities to the Repository, for any ADD, UPDATE, DELETE

And my Repository will be creating Models from Entities when returning results of a select LINQ queries.

Any thoughts if I'll be in a greater problem later if I choose to go with the above design?

If the above design is not a good solution, any other advise?

Answer 1

You're using the wrong repository approach, the anti-pattern. The Repository makes sens only as a decoupling pattern i.e you want tot decouple the Business Layer(BL) from the Persistence Layer(PL).

This means, your Bl (and services) don't know about EF or any other ORM. This means that your repository interface only know about what BL knows,that is the business objects. Your repository should NEVER expose EF, IQueryable or other PL detail.

First of all you need UoW pattern ONLY when updating a model, never just for queries. Then, when you're asking the repository for something, you tell it what you want and the repository will use EF, create queries, joins etc and maps the query results to the POCO the repository returns . So the mapping from EF entities to domain objects is done inside the repository.

Actually, ALL work related to the database via EF (or any other ORM) is done inside the repository. The BL just gets their object in the final form. That's the whole point of the repository.

What you're doing now is wrong, because you are doing repository's work at the BL level, violating the Separation of Concerns principle. The proper use of repository is like I wrote above.

P.S: In case you wonder, the generic repository is an anti pattern, stay away from it. As a side note, a generic repository interface is not the same thing as a generic repository.