Timeline for Stateless Web Applications Defeat DBContext Somehow?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 24, 2015 at 21:39 | comment | added | Robert Harvey | You can, but then you'd have to store it as a member variable of the repository or service layer. You'd have service layer methods representing incomplete transactions (not units of work), and that wouldn't be good either. | |
| Jan 24, 2015 at 21:39 | comment | added | user1172763 | OK, I get it. It just seems strange (to me) to say that the request/response model "prevents the default functionality of Entity Framework from working". I would have just said something like "you can't leave DBContexts open for subsequent requests in the same session, and that presents some architectural issues". | |
| Jan 24, 2015 at 21:36 | vote | accept | user1172763 | ||
| Jan 24, 2015 at 21:35 | comment | added | Robert Harvey | I am saying that session state would be handled some other way than holding a DBContext open. The SESSION state might be persisted to the database between pages, for example. Or, it can be held in a browser cookie or hidden page element. | |
| Jan 24, 2015 at 21:12 | comment | added | user1172763 | Thanks... so are you saying that ideally one would use a single DBContext instance from the initial creation of the session shopping cart through check-out (or abandonment of the cart)? If that's what you mean, then I can certainly see where an ASP.NET MVC application might not lend itself to that. | |
| Jan 24, 2015 at 21:08 | history | answered | Robert Harvey | CC BY-SA 3.0 |