Timeline for Database first entity framework, repository, service, UnitOfWork pattern
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 23, 2014 at 9:23 | vote | accept | user2945722 | ||
| Apr 22, 2014 at 21:56 | comment | added | dreza | @user2945722 I guess I would have my service layer do most of the logic. So needing a generic GetWhere off that might not be needed as instead it would expose methods like GetActiveGroup and GetRelatedGroupsTo i.e. buiness rule type methods | |
| Apr 22, 2014 at 21:55 | comment | added | dreza | @user2945722 rather than manually edit the auto generated class you could create a partial DbContext and make that one implement your interface | |
| Apr 22, 2014 at 11:26 | comment | added | user2945722 | Ah I see, so you would manually go into the DbContext class and make it implement your IUnitOfWork (I am using db first so this is generated for me, but i could still edit it every time i regenerate the database) So the interface would not need the methods like "GetWhere" defined as my original comment suggested. | |
| Apr 22, 2014 at 11:12 | comment | added | user2945722 | Thanks for the feedback. I think i understand, so your UnitOfWork class would act like the repository as-well including methods like "Find". (For my example i may add "GetSingle" and "GetWhere" as seen in my original post). Should these methods also be in the IUnitOfWork interface? And then when you come to consume the services you would create an instance of the service and pass through the UOW, instead of interacting with the UnitOfWork directly (via it's properties) as i did. Am I understanding this correctly? | |
| Apr 22, 2014 at 10:52 | history | answered | dreza | CC BY-SA 3.0 |