Timeline for Best practice for transaction handling using Entity Framework
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2019 at 13:35 | answer | added | Flater | timeline score: 1 | |
| May 17, 2019 at 15:31 | comment | added | Rahul Jain | What did you do finally? | |
| Jan 31, 2018 at 9:40 | comment | added | Laiv |
If I use request scoped dbcontext using DI container. That's the problem. Never start the transaction at so high level. Web API, CLI, etc are mere controllers, drivers, but are not bound to the logic. Transactions start where the business start (ideally). This approach is very similar to the anti-pattern Open session in view; which it was very common some years ago.
|
|
| Jan 31, 2018 at 6:03 | comment | added | Rumit Parakhiya | Let us continue this discussion in chat. | |
| Jan 31, 2018 at 6:01 | comment | added | Rumit Parakhiya |
@RobertHarvey Then provide a single service method that performs both tasks May be I wasn't clear enough, or I'm not following you. My Repositories inject DbContext through constructor injection. In Scenario 2, there is a single service method which does both the tasks, but both tasks are being done in separate services, which have their own repositories. Am I missing something quite obvious here?
|
|
| Jan 31, 2018 at 6:00 | comment | added | Robert Harvey | No, but there would almost certainly be some sort of method call to a repository or service layer. Why couldn't you configure AutoFac to provide a new instance every time that method is called? | |
| Jan 31, 2018 at 5:59 | comment | added | Rumit Parakhiya | @RobertHarvey I'm using AutoFac for DI and it can be configured to provide new instance for every web request. So using that would serve the purpose for web api, as all services requiring DbContext would get same instance when asked for in same web request context. But in case of CLI or Win service, there wouldn't be an Http request context at all. | |
| Jan 31, 2018 at 5:57 | comment | added | Robert Harvey |
In scenario 2, I would want both those operations (changing user's status and closing their pending tasks) to be done in a single atomic transaction. -- Then provide a single service method that performs both tasks.
|
|
| Jan 31, 2018 at 5:56 | comment | added | Robert Harvey |
EF doesn't need a RequestContext to work properly.
|
|
| Jan 31, 2018 at 5:55 | comment | added | Rumit Parakhiya | @RobertHarvey, 1. There wouldn't be a RequestContext when I consume the service from CLI app or Win service. 2. In scenario 2, I would want both those operations (changing user's status and closing their pending tasks) to be done in a single atomic transaction. | |
| Jan 31, 2018 at 5:55 | comment | added | Robert Harvey |
While in Scenario 2, user service should create a transaction and task service should join the already open transaction. -- Why?
|
|
| Jan 31, 2018 at 5:54 | comment | added | Robert Harvey |
If I use request scoped dbcontext using DI container, it'll do the job for web api, but won't work for service requests coming directly from CLI app or windows services. -- Why?
|
|
| Jan 31, 2018 at 5:50 | history | asked | Rumit Parakhiya | CC BY-SA 3.0 |