ORM (Entity Framework) and Repository Pattern Conflict
C#.net and Entity Framework Version
If you’ve come across some steps in your programmer life, you will have been certain to encounter the term “Design Pattern”. And, I’m sure that you will like it. And you will proud of knowing these “Design Patterns”. But these so called “Design Patterns” are like a knife. If you skill-fully utilise in correct situation, you will get a lot of benefits from it. Otherwise you will get end up with bleeding yourself.
Defining Repository Pattern
These days a lot of programmers talk about “Repository Design Pattern”. Generally, it can be assumed as:
Repository pattern is used to create abstraction layer between your business logic code and the data access layer. Your application code (business logic code) does not need to know how their business data are saved into the database. They only need to instantiate and use the Repository class.
Why we have to use this Repository Pattern in our project ? Good question. In old days (before ORM frameworks birth), we had very often fell in the situations of SQL queries scattered in our codebase. And when we come to modify a column to a table, we have to search several code files and find usages of the table. That was pain.
By using Repository pattern, we would only necessary to change one Repository class in the same situation. Because all the knowledge of persistence, including mapping from tables to objects, is safely contained in this Repository class.
For more practical understanding, you should read this article on Code Project. There also have a ton of articles on Google.
But some programmers addicted to the pattern. They try to use the pattern in all possible means rather than considering why and how to use effectively. Don’t surprise it! I was also the one of them. It’s quite funny.
Today .NET technology is changed so much from its version 1.1 days. The addition of Entity Framework ORM to the .Net family is also quite good change from its old days.
Defining Entity Framework
Entity Framework uses one common syntax (LINQ) for all object queries whether it is database or not . It’s pretty fast and straight forward, easy business objects mapping, less coding required to accomplish complex data manipulation tasks.
Actually, what Entity Framework trying to do is solving the problems that we previously solved with the Repository Pattern. I mean “Isolating all of data manipulation complexity behind the wall of a convenient interface and class, keeping the complexity of data access code away from actual business logic code”.
Entity Framework take care of our connection strings, authentication and connection management, SQL query generation, transforming raw data returned from the database into business domain objects.
Ok, that’s what our UoW (Unit of Work) class and Repository object normally do in our Repository Pattern, isn’t it?
In my opinion, I am not sure Entity Framework is already in Repository Pattern. But I strongly believed that wrapping Entity Framework in Repository Pattern is just redundant and makes the data manipulation process more complex.
The worst problem is that you lose all the advantages to use several built-in functions and automated mappings from Entity Framework by wrapping in your own POCO repository object. These built-in functions and automations are the main reasons why Entity Framework is so much powerful. It means if you lose these features, you also lose the power of the framework.
Argue, argue, argue
Most people argue that you can easily change your Data Storage Technology by wrapping in Repository Pattern. For me, it’s pretty awkward argument. I think that vertical pilot change to new Data Storage Technology is quite rare in real environment. If it really happen, you’ll have to take considerations in various aspects of the system. Not just Repository pattern can solve all the problems. Also remember that Repository pattern is not implemented for this purpose, it’s for data access abstraction.
Repository pattern is not implemented for this purpose, it’s for data access abstraction.
Even if that awkward situation happen unfortunately, Entity Framework would still handle it. Currently it supports MsSqlSERVER, SQLExpress, LocalDB, AzureDB and even MySQL.
My final point
In my concept, the abstractions (logics) that we put on our systems should provide significant value, else the overhead of defining and maintaining them ends up as a net-negative for our project.
Every abstraction we use needs to pass this result of viability — any whose costs exceed the benefits is hampering our work, not benefiting it.