We as developers tend to apply the same techniques to solve every problem thrown at us. We learn a new design pattern and all of a sudden that pattern is all over our codebase. We find a new way of writing code and we apply it wherever we can because we are very excited about it or because it feels like it could simplify our solution.

In the past few years, particularly in .Net space, there has been a lot of excitement about ORMs, and when we get excited about something we overuse it. There are scenarios where using ORM is not a good idea, and there are common ORM anti-patterns that could severely impact the project architecture, maintainability, user experience and database and network load. In this series I will try to cover issues I have come across as well as their solution. In this series I am not going to show you how to use a particular ORM and you may not even see any code. I assume that you know your ORM; however, I will try to provide some links to ORM related patterns for those not familiar with inner workings of one.

Below is the list of articles in no particular order:

Never ever one size fits all and this applies to my solutions explained as part of this series. Think about your problem, your requirements and your constraints, know your choices and make an informed decision.

Are these really anti-patterns or am I over-designing?

I call these anti-patterns only because they are used where they should not be and because I see them used incorrectly very frequently. In other words, some of these patterns are used as one-size-fits-all and are thrown at any and all persistence problems without any thought. I have used and will use some of these patterns in my code if they fit my requirements/context.

This series is about issues I have with these patterns; so I am going to do my best to highlight their issues. That said, I will also try to explain where each pattern fits.