Repository Pattern: Strategies for Performing
How you can have the best performance in the persistence layer and keep using ORM?
Join the DZone community and get the full member experience.Join For Free
A while ago, my friend Gustavo Gomes and I were talking about persistence strategies and as you can imagine, we drank a lot of coffee.
The center of the discussion was how to get good performance using an ORM, like Entity Framework or JPA. We know that there are some features that we can set in other to improve performance in an ORM, but often times we don’t get a good result, and the client...
So, how can you have the best performance in the persistence layer and keep using ORM? This point is polemic, I know! But the question should be: Should we stay stuck only on ORM? Why not have a Hybrid Persistence Layer, approaching ORM and JDBC [Java] or ADO [.NET]?
At the first glance, it might seem crazy or unnecessary. Yes, it seems. But if we bring the client to the center of the question, we will see that pure Persistence layer or Hybrid layer doesn’t matter to him. He needs good performance.
If you, like me, are concerned about your client, but also want to appropriate the benefits of ORM, here are some are some approaches that I’ve been using.
In .NET, I use Entity Framework as the Write repository and Dapper as the ReadOnlyRepository. In this case, I just use Entity Framework to reading to attach entity, before updating a register. In some cases, I use the infamous ADO with executereader, for example. But this last case, only when I have to have queries.
Talking about .NET, The picture below shows a comparison among the main options for persistence.
In terms of designing of code, you might be free for your decision, but considering best practices preconized by SOLID principals.
Consider being flexible when designing software.
Opinions expressed by DZone contributors are their own.