简体   繁体   中英

Entity Framework + Windows Forms: Lifetime and Data Binding

I have a Windows Forms application with forms like:

  • MainForm
  • FirstForm
  • SecondForm
  • ...

The main form is started from the beginning and ends after the application exist. When i use one context per form, are the lifetime for the main form not to long? The second problem which i have with one context per form is that i always have to work with detached entities.

EDIT: I need always to reattach the entities like:

_context.MyEntities.Attach(existingEntity1);
_context.MyEntities2.Attach(existingEntity2);

existingEntity1.MyEntities2.Add(existingEntity2);

_context.SaveChanges();

That sees a little odd to me.

What is the best practice for lifetime handling and how can i resolve the detached problem when i use one context per form?

Now my data binding looks like:

var myEntities = from e in _context.MyEntities
                 select e;

var bindingList = new BindingList<MyEntity>(myEntities.ToList());
myGridView.DataSource = bindingList;

Say the MainForm, FirstForm and SecondForm needs the same bindinglist but do different things, whats the best practice to share the binding list?

The recommendation is a context per form.However if using the same context in multiple forms has a benefit to you -- be it faster development and/or better performance if working on the same entities -- and that outweighs the risk of a long lived context -- being too many entities loaded and concurrency issues -- then use the context across multiple forms. Perhaps there is another event in your parent form that can be used to trigger disposal and recreation of the context to lessen it's lifetime if it becomes a problem?

Another option is to assess whether your forms can be altered to represent more discrete units of work where you may not have to operate on so many common entities and thus fewer detached entities.

EDIT: As noted in the comments, this answer is not Microsoft's current recommendation. It is potentially appropriate for complex object models and cases where the model is detached from the context.

For your first question I would say the context is too long lived. Short lifetimes are usually better.

For your second question, I would look into Self Tracking Entities if you are frequently dealing with detached entities.

For your third question, it depends what you are doing with the data. If it is for read only use, then you can bind the same data to the same instance without too many issues. If it is for making updates, then it depends on the business domain. In some cases, you might consider 'cloning' the data to keep the data separate. But it might also make sense that each form sees the same single instance so that all forms are showing the same version of the data. A change on one form shows up on the others. In either case, Self Tracking Entities can work well.

I have a sample showing the use of Self Tracking Entities in a WPF app .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM