In modern software development, clean and maintainable code is paramount. The Repository Pattern is one of the design patterns that help achieve th...
For further actions, you may consider blocking this person and/or reporting abuse
I'm with Bradley. It's an anti-pattern because EF already implements the Repository and Unit of Work patterns. Basically you're adding the repository pattern over the repository pattern. See dev.to/anthonytr/why-you-shouldnt-... and search the net for "IRepository antipattern" to find many discussions on the topic.
Thank you for your thoughtful feedback! I completely understand the point about the redundancy of adding a repository pattern over Entity Framework, especially since EF already implements both the Repository and Unit of Work patterns internally.
You mentioned that this could also impact testability. In that regard, if I were to skip the custom repository pattern and work directly with EF, how would you suggest mocking or unit testing the DbContext? I've found that mocking a custom repository interface is relatively straightforward, but I’d love to hear your thoughts or best practices on mocking DbContext itself in unit tests.
Thanks again for sharing your insights—I'm always looking to improve my approach!
Answering your query properly is beyond the scope of a comment. I'm putting together a working version of what I currently do here - github.com/ShaunCurtis/Blazr.Demo
All fine to use the repository pattern in certain scenarios. After 30yrs of development, however, I've long taught it's an anti-pattern.
Better to nest the full logic to a command / event pattern and write a simple adapter or facade over the data layer. The full logic and query syntax (includes, filters, other) are almost always highly unique to that command. Rarely do commands need to be shared. There are ways to accomplish it via command chaining or optional pre/post processing checks but those are almost always avoided in favor of a better design / separate command.
Thank you for sharing your insights!In my article, I focused on the Repository Pattern as it's often a good starting point for developers working on simpler applications or those who are newer to designing data access layer
thanks for sharing this insightful information about the Reporisotry pattern
you are welcome
What is the solution in your opinion to select required fields only but keep using this pattern .? Example- only product id..
use dto like example
public class ProductIdDto
{
public int Id { get; set; }
}
Thanks for the clear explanation.
you are welcome