Thoughts about repositories and ORMs or why we love rocket science!

[utterances-bot]

Thoughts about repositories and ORMs or why we love rocket science!

https://asp.net-hacker.rocks/2019/02/20/repositories.html

[lennybacon]

You should take care of IDisposable :-P

[JuergenGutsch]

@lennybacon For sure :-D

[jakenuts]

I’ve made all these mistakes, happy to be returning to just using the ORM but I’m struggling with real world applications.

What arrangements have you found that eliminate the intermediate wrappers but allow for projecting, enriching and caching the data coming out of the context? I’m starting to move toward Mediatr and single handlers for each data request but while it works and only uses the dependencies necessary for the specific request it also feels a bit scattered.

Would love to see examples of how people are using/enhancing DBContext in requests that are more than the simple “query and project” samples.

[lennybacon]

@jakenuts When talking about wrappers but allow for projecting, enriching and caching the data coming out of the context, do you mean projections like with CQRS?

[JuergenGutsch]

@jakenuts That's what I planned to describe in one of the next posts. The patterns I usually end up with, when I think about the architecture of bigger real world applications. In short: I usually end up with a kind of CQRS.

[SebastianStehle]

I think a common misunderstanding of the repository pattern is that in all samples it is used for anemic domain models where the domain models or business objects are just data and have no behavior. This is okay but there are also use cases and architecture styles where it might be helpful to have rich classes with well defined business operations. In these cases you don't want to have public setters and you might have value objects that are not easy to map for your ORM framework.

[JuergenGutsch]

@SebastianStehle absolutely!

[lennybacon]

@SebastianStehle I differentiate them by naming them the Fowler Repository and the Evans Repository.

[lutticoelho]

I changed the ORM once in a project beacause performance issues. But was a very specific problem and I still think was a configuration problem, and not a ORM problem. The good part of use Repositories with dependency injection was that we just create one new repository with the same interface using the good and fast DataReader and boom... Problem solved. I beleave that is most commom to change the ORM than change the Database. How many times did you hear about a company change its database?

I agree that repositories should be implemented with operation focus and not in table focus. In real world scenarios most operations uses and changes data in lot of tables and we shouldn't need to use more than one repository to perform this kind of operations. However, we still have to implement basic CRUD operations and generic repositories is very good for it. So whats my conclusion? We need to use the rigth tool for the job. If we need to break a wall, a hammer is perfect. But if we need to make a jewel, we will use a diferent kind of hammer, or any other tool that a goldsmith uses.

Congratulations on the great article, as always.

I'm waiting for the CQRS one. :)

[lutticoelho]

And yes. I love rocket science. But I also like it when someone shows me a simpler way to get the same result.

[JuergenGutsch]

Hi @lutticoelho Glad you like it :-) Many thanks for your comments and your thoughts. We all love rocket science :-) I'm still working on the CQRS post. I need to rethink the structure of that post. While writing I get more and more Ideas to write about and at the end the post will be longer than expected. Currently It's to huge :-D