Last post Dec 28, 2015 03:44 AM by Kelmen
Dec 27, 2015 04:17 AM|Alex71938|LINK
Seems like there are a lot of recent changes and confusion in Web API team, the scaffolding suggests to initialize and dispose DB context in every controller. Hm, what about DRY? How about UserManager?
Ideally I want to access DB context and UserManager from Web API controllers and don't bother to dispose them. I want them also to rely on the same OWIN context so that there are no DB collisions
Dec 28, 2015 03:44 AM|Kelmen|LINK
in web development, means for state-less, db resources should be created as needed and drop/disposed as when service is done.
unless ur architecture for some reason need to hold onto a db resources through out a specific object/sys lifespan, though i doubt this is what u needed, because only architect should bother with this.
if u not familiar with this, but worked out a way to hold onto a db context statically in the web lifespan, u likely will encountered other db issue, like timeout, transaction control conflict, connection issue, etc.
I would suggest do all ur data access stuffs in a separate class library, without relying and coupling to the web api framework, which is what i been doing, and so i have no concern with changes by web api over db stuffs, as web api is not mean to do anything