Say NO to Repository Pattern with Entity Framework

You have been told that you should implement some kind of architectural pattern (insert your own here) in your code to feel safe and future ready? While patterns might make sense for large, enterprise level projects and teams, they usually do not play well in agile development and in agile teams. Following patterns might feel like coding by the book, but books are written by the people that do not spend days in the office programming for real-world project. Remember that!

They have told you that by following pattern you will be able to change database later on? Really!? I have not changed a database in none of the projects delivered in my carrier (20+ years in development business). I don’t like to work for something that will not happen. And you?

You cannot test the code without implementing some kind of pattern? It is just not true. You can test code without utilizing patterns.

I have lately seen projects that implemented repository pattern along with the UnitOfWork pattern on top of the Entity Framework. That is a big stack of code doing nothing. Entity Framework, by itself, already implements a repository pattern. Implementing another layer on top of this is not only redundant, but it makes maintenance harder. It is not easy to understand Repository<T> code. Implementing a pattern limits you from using new functionality of frameworks.

Remember: Your product will not benefit from any kind of pattern you use. Work on features, not on implementation of patterns.

No comments:

Post a Comment