Timeline for Repository Pattern with Services Layer - Good Practice?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 11, 2021 at 8:48 | vote | accept | Subliminal Hash | ||
| Oct 30, 2020 at 11:56 | answer | added | Flater | timeline score: 7 | |
| Oct 30, 2020 at 10:12 | comment | added | Rik D | This is probably not the place to discuss Mosh's video, but to counter his arguments: Duplicate Query Logic -> If this is a problem you have, you can use Query Objects to solve it. Decouples from framework -> If you choose EF you commit to that choice, it's unlikely you switch to NHibernate. When using a repository, you loose many of the benefits of EF. Especially in a simple CRUD project. | |
| Oct 30, 2020 at 9:20 | comment | added | Subliminal Hash | @RikD things are getting interesting now.. :) Then there is this | |
| Oct 30, 2020 at 7:50 | comment | added | Rik D | Since you mentioned EF and Repository/UoW, you might want to read this answer: Why shouldn't I use the repository pattern with Entity Framework? | |
| Oct 30, 2020 at 6:57 | comment | added | Subliminal Hash | @FilipMilovanović thanks for the comment. So how can I implement this idea with a generic service? (if it is possible of course) He also registers services in the Startup.cs As you said, for most of the entities the generic repository is more than enough form me as the need for anything other than the basic CRUD will not be needed for ever. But I am quite new to the concept to figure out how to implement it to this code. Any ideas? | |
| Oct 30, 2020 at 6:25 | comment | added | Subliminal Hash | @EricKing thanks for the comment. I've come accross to one of your answers to a similar question and the accepted answer here. However it has been 8 years since that. Could you let me know if your answer is still valid for that question? If not could you answer the very same question in today's time? | |
| Oct 30, 2020 at 3:09 | comment | added | Eric King | No matter what architectural style you use, an application 28 entities is going to have a lot more code than one with 2 entities. I personally don't use the generic repository pattern and unit of work pattern that the author uses, but his approach is pretty solid in general and pretty common in the industry. | |
| Oct 29, 2020 at 21:26 | comment | added | Filip Milovanović | You don't need 28 repositories, it's not supposed to be a repo per entity. Probably 3-5 or so will do. Organize the repos (and your objects) around your use-cases, so that for a use case a repo can return the objects you need together (in one or in a few method calls). E.g., his MusicRepository.GetAllWithArtistAsync() returns Music objects and the associated Artist objects. The top-level objects can, but don't have to be EF entities. | |
| Oct 29, 2020 at 20:55 | review | First posts | |||
| Nov 12, 2020 at 21:02 | |||||
| Oct 29, 2020 at 20:53 | history | asked | Subliminal Hash | CC BY-SA 4.0 |