Test and validate data binding experiences with WPF and Windows Forms

[ajcvickers]

Especially targeting .NET Core 3.0

Things to consider:

• Correctly implementing notification entities, including navigation collections
• What to bind to (see also Databinding: Guide users to not bind against DbSet.Local directly efcore#8898)
• Configuring EF to use notification entities for change tracking
• Dealing with store generated values
• Lazy loading

[sjb-sjb]

A few comments based on my experience with notification entities.

• Would certainly suggest including UWP in the platform list. I believe the issues are similar.
• Broadly speaking it makes sense to use notification entities in a UI application because notifications are needed anyway to push info to the UI.
• Since @ajcvickers alluded to "correctly implementing" notification entities,let me ask, is there a known problem?
• Concerning "What to bind to", my personal opinion is that Microsoft should build a complete view model system that integrates with EF. This should include paging appropriate for data virtualizing list view. Also a view model system for individual properties including property errors -- perhaps along the lines of the Template 10 view models.
• I didn't have any problem configuring EF to use notification entities.
• Concerning store generated values, the questions are different for Id's than for, say, concurrency tokens. As I recall, if I notify a change to an Id after a SaveChanges then EF throws an error saying that the primary key cannot be set at that time.
• Overall it seems to me that some clarity should be brought to the timing of property change notifications and how these might interact with entity state change notifications. Are there restrictions in setting/notifying properties within state change callbacks? How long after setting a field can we notify the property change?
• In my implementation I did end up setting EF to write to fields. It was too difficult otherwise to sort out what property notifications were coming from EF vs my application. I wonder if it would make sense to consider having a separate event from EF when a field assignment occurs -- i.e. DbContext.FieldChanged rather than entity.PropertyChanged. It goes with the theme of lifecycle hooks.

[ajcvickers]

Smoke test only for 3.0

[ajcvickers]

Tracking as part of #778