> Indeed. It's EF poor design, that they try to rework in EF core.
> Still there are plenty of workarounds for this. For example attaching
> entities only by ids.
Attaching by ID? It's still attaching...
> DbContext is supposed to be used in request-response scenario (web
> sites, for example), w
> That doesn't make any sense. If I dispose context after query then I
can't update the entities without attaching them to new context. Waste
of resources.
Indeed. It's EF poor design, that they try to rework in EF core.
Still there are plenty of workarounds for this. For example attaching
entitie
> > d) Do I need to dispose the the context on closing the window?
> Not only on that. you should create and dispose context for every
> action you do with a database: insert, delete, update, query etc.
That doesn't make any sense. If I dispose context after query then I
can't update the entities
EF context is implementation of unit-of-work pattern, it is not
repository pattern.
> d) Do I need to dispose the the context on closing the window?
Not only on that. you should create and dispose context for every
action you do with a database: insert, delete, update, query etc.
> 3. As lo
> a) Is the method described above considered as good practice?
From what you've written, yes.
> b) Basically it is a connected Context until the user refreshes the data.
> In
> this case the context is recreated.
No problem with that.
> c) In order to manage multiuser environment, do I need to
