dimanche 17 décembre 2017

Should you or should you not use Repository / UoW with EF

So same old question, should you or should you not use a Repository / UoW pattern with Entity Framework ?

I've read articles that clearly state that Entity Framework is a Repository and UoW itself and I agree to that.

And articles that and quot from microsoft

The repository and unit of work patterns are intended to create an abstraction layer between the data access layer and the business logic layer of an application.

and msdn

Directly accessing the data can result in the following:

Duplicated code
A higher potential for programming errors
Weak typing of the business data
Difficulty in centralizing data-related policies such as caching
An inability to easily test the business logic in isolation from external dependencies

Which I also agree with, especially on the matter of avoiding having duplicate code.

So, I find it confusing whether to use repository and UoW.

How to avoid duplicated queries? Shouldn't you use something generic, like a Generic Repository and at least handle basic CRUD operations ?

And in the same time how not to over-engineer and use the patterns wrongly?

What might be the situations where you should apply a Repository and UoW pattern, and since not everyone tests the code let's say you don't care about testing the application ?

Thanks

Aucun commentaire:

Enregistrer un commentaire