locked
Repository pattern questions RRS feed

  • Question

  • User-375835195 posted

    Hello guys!

    I implemented a generic repository pattern. So far, I've been using a non-generic implementation similar to the one from the docs.

    There is some misleading information on stackoverflow, so I decided here. You know, it's better to ask than keep doing it wrong all the time. All questions are related to the GitHub project linked below.

    1. Should UserRepository`and RoleRepository implement IDisposable and dispose SaveBeesContext?
    2. Any suggestions about UserRepository.GetByEmailAsync and UserRepository.AddInRoleAsync? Are they on the right place?
    3. What about how classes and interfaces/files are structured in the folders?
    4. Anything else related to the repository/service model that I'm missing?

    https://github.com/Hulkstance/savebees

    Friday, October 4, 2019 11:51 PM

Answers

  • User-375835195 posted

    mgebhard

    Hulkstance

    Thanks, anyway I understood that it's pointless even for unit testing. I will just ignore it unless I have to use another database.

    What is pointless?  What are you ignoring?

    It's pointless to use repository model because EntityFramework Core does the same thing. Unless it's something else not supported by EF, this model is waste of time. For unit testing I can use in-memory database which was the purpose of that model.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, October 15, 2019 8:04 AM

All replies

  • User-474980206 posted

    Should UserRepository`and RoleRepository implement IDisposable and dispose SaveBeesContext

    >> yes, otherwise the code is leaking sql connections and will fail under load.

    Any suggestions about UserRepository.GetByEmailAsync and UserRepository.AddInRoleAsync? Are they on the right place?

    >> Maybe. I'd prefer the UserService had this logic, rather then placing business logic in a repository. The repository should be a thin facade over the database access.

    What about how classes and interfaces/files are structured in the folders?

    >> I think the structure is wrong for a large project (but fine for a simple example). If its worth using the repository pattern, it should be done correctly. the repository interfaces should be in their own project along with the repository entity definitions. the implementation of the repository should be in its own project.

    Anything else related to the repository/service model that I'm missing?

    >> the repository pattern is to allow the replacement of the database access libraries if desired. But the repository does not abstract query clauses, and thus your code is pretty bound to EF. It hard to under the point in this case. after all, EF also implements a repository pattern. 

    Hard to know what this buys over EF with custom contexts other than more code. Also you have the service layer over the repository. 

    Saturday, October 5, 2019 12:32 AM
  • User-375835195 posted

    Thank you for your answer!

    bruce (sqlwork.com)

    Should UserRepository`and RoleRepository implement IDisposable and dispose SaveBeesContext

    >> yes, otherwise the code is leaking sql connections and will fail under load.

    I implemented it and updated the code.

    Saturday, October 5, 2019 11:55 AM
  • User-375835195 posted

    I updated the code and added UnitOfWork.

    Could you please check https://github.com/Hulkstance/savebees/blob/master/back-end/SaveBees/Repositories/UnitOfWork.cs. When DI'd, should it be singleton or scoped?

    Monday, October 7, 2019 11:04 AM
  • User475983607 posted

    It depends on the scope of the context.  If the context is configured as scoped then the UnitOfWork should be scoped as well.

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.0#singleton

    Monday, October 7, 2019 12:02 PM
  • User-375835195 posted

    It depends on the scope of the context.  If the context is configured as scoped then the UnitOfWork should be scoped as well.

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.0#singleton

    Thanks, anyway I understood that it's pointless even for unit testing. I will just ignore it unless I have to use another database.

    Monday, October 7, 2019 12:09 PM
  • User475983607 posted

    Thanks, anyway I understood that it's pointless even for unit testing. I will just ignore it unless I have to use another database.

    What is pointless?  What are you ignoring?

    Monday, October 7, 2019 2:07 PM
  • User-375835195 posted

    mgebhard

    Hulkstance

    Thanks, anyway I understood that it's pointless even for unit testing. I will just ignore it unless I have to use another database.

    What is pointless?  What are you ignoring?

    It's pointless to use repository model because EntityFramework Core does the same thing. Unless it's something else not supported by EF, this model is waste of time. For unit testing I can use in-memory database which was the purpose of that model.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, October 15, 2019 8:04 AM
  • User1120430333 posted

    mgebhard

    Hulkstance

    Thanks, anyway I understood that it's pointless even for unit testing. I will just ignore it unless I have to use another database.

    What is pointless?  What are you ignoring?

    It's pointless to use repository model because EntityFramework Core does the same thing. Unless it's something else not supported by EF, this model is waste of time. For unit testing I can use in-memory database which was the purpose of that model.

    Yes EF uses the repository pattern. If you are not using the repository pattern, then what are you using?

    Tuesday, October 15, 2019 11:34 PM