As you said, bringing in 3rd party libraries in your codebase makes you responsible for it, so for the most of my work I prefer to "reinvent the wheel" so to speak, but I must admit in the past I was using Dapper (until I've became proficient in EF Core)
Interesting. Would not figure for MediatR as number one. I could be totally wrong of course, but I myself would go: Project: AutoMapper, AutoFac, FluentValidation Tests: AutoFixture, Moq, FluentAssertions
This is not about being wrong or correct. It's about what tools we use that help us to deliver better software. I have one question tough. What are the benefits of using a 3rd party DI container? I have never used one in .NET Core apps.
Dapper would probably make it to a close 4th place. But I don't really use it on every project. I use it just where I have some complex querying to do.
I can't contraddict you with this. in the end I think this is also a matter of personal taste. But for me, behavior pipelines and notifications are features that help to keep the code clean, well organized, easy to understand and easy to maintain. I worked mostly on LOB apps and I have never encountered a project till now where the complexity of MediatR outweighs its benefits in the long run. I'm also curious, how would you handle cross-cutting concerns in your app without MediatR? Would you manually create your own decorators? Would you use another library like Scrutor?
@@Sebastian-sk2wu I have never used MediatR, but my first impression was the same. It looks like a bunch of bloat. Can someone help me understand a use case where this solves a programming issue? I'm really just looking for context on it's usefulness.
