locked
In a WPF Application: "global DbContext" or "multiple DbContext"? RRS feed

  • Question

  • Hi all,
    I'm planning a WPF application where I'll use EF Code First and I'm thinking about how to use DbContext.
    The application will be like the classic Word, Excel, ecc. where the end user opens a file, the application main window shows the file content and there are several secondary windows that edits, modify, ecc. data of the opened file.
    But, once opened a file, the main window will always stay opened, displaying the file content and edits.
    In this scenario I am thinking if it's better to have a single, application level, DbContext, or to have 1 DbContext for the main window and every secondary window have it's own DbContext

    The first choice, as I read in forums, is deprecated, and has the disadvantage that validate data is not easy.
    For example, an opened secondary window should validate data before commit its changes, but model can't validate data until it's updated, and as the window commit data to the DbContext, every other opened windows will reflect immediatly changes...

    The second one is what I think I will follow, so every windows will have its own DbContext, but how to manage to "refresh" the DbContext of the main window (which stays always opened) so it reflect changes done in others windows?

    Thanks

    Thursday, September 22, 2011 8:43 AM

Answers

All replies

  • Hi FraCal,

    Welcome!

    According to your description, you said validation is disadvantage for the first choice, I'm not very sure about your point. I think the disadvantage should be memory consumption, one DbContext will track all objects graphs. When you add new object in first window,  the object will be tracked in DbContext, the secondary window can retrieve the first window's object from same DbContext.

    >> how to manage to "refresh" the DbContext of the main window

    The only way to refresh is re-binding, add new button click event-->retieve the records by new DbContext instance, but the performance is not good, this is just a work around.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, September 23, 2011 2:57 AM
  • Hi Alan, thanks for your response.
    What I mean is:

    In the first scenario, the second window controls must update their Source if data validations are passed. Data validation can't be performed while tabbing from a textbox to another one, but explicitly when the user press the Ok button. I have property level validation rules (required, range, ecc.), Entity level validations, but also DbContext level validation rules.
    I mean: datas inserted in second windows must also be validated at DbContext level, because others related entities my not accept that the secondary window is inputting that datas.

    That said, using UpdateSourceTrigger=Explicit doesn't not update the source until BindingGroup commit the ProposedValues (and this is ok for me), but this way the Entity properties doesn't have proposed values and the IValidatableObject.Validate method validates on "original" values, not the proposed ones. And this is not good.

    I don't understand if I have to write two copy of the same validation rules, one used when the object is created and edited by code, and the other when the object in edited by windows and BindingGroup.

    The second problem is: how can I revert data if user cancel the editing? Code First is not capable of this, so I think I have to code this.

    Are there code samples on these two problems? I'm searching for but seems nobody encounters them, while I think are a common scenario

    Thanks

    Friday, September 23, 2011 8:12 AM
  • Hi FraCal,

    Thanks for your feedback,

    To tell your truth, I'm not good at WPF, Validation is the last line of the defense before saving changes to database, you can use Data Annotations to validate your input, the more information you can refer here: http://blogs.msdn.com/b/adonet/archive/2010/12/15/ef-feature-ctp5-validation.aspx

    I think you can use ObjectDataSource to handle WPF: http://blogs.msdn.com/b/adonet/archive/2011/03/08/ef-feature-ctp5-code-first-model-with-master-detail-wpf-application.aspx

    >>how can I revert data if user cancel the editing?

    if you cancel the editing, it has't save to database, so you can refresh the item.

    Have a ncie day.

     


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by FraCal Friday, September 30, 2011 8:52 AM
    Thursday, September 29, 2011 8:38 AM
  • I missed the docs in your first link, it clarified some doubts.

    I'm going to use a "global" (application level) DbContext, every Entity will implement IEditableObject, IValidatableObject, INotifyPropertyChanged, so it can notify changes on demand after the validation as success and revert data using IEditableObject.CancelEdit().

    Thanks

    Friday, September 30, 2011 8:51 AM