【发布时间】:2019-08-01 15:19:19
【问题描述】:
因此,我们正在将旧的 wpf 应用程序移植到 .net core wpf 中。作为努力的一部分,我们还将数据层移动到EF.net core。
- 由于我们使用 Prism MVVM,在 DI 服务上下文中,我们保留了一个实时数据上下文,用于跟踪用户通过 wpf 前端和服务显示和编辑的实体。
- 为了实现“撤消”功能,我们使用以下方法跟踪对象
entity.HasChangeTrackingStrategy(ChangeTrackingStrategy.ChangingAndChangedNotificationsWithOriginalValues);
在编辑时,对象会更新,在 Reload() 时,它会从跟踪的原始值恢复。就对象而言,操作还可以,但是,wpf 方面却无法正常工作。似乎 ef.net 核心是 wpf 应用程序的一个非常不适应的公民,假设它是 INotifyPropertyChanged 机制的唯一受益者。当然,这对于 WPF 来说一点也不真实。
- EF.net 在加载、重新加载等时似乎不使用属性。它直接作用于基础字段。因此,NotifyPropertyChanged 永远不会触发,因此网格永远不会用新数据刷新,比如
dbContext.Entry(c).Reload();。那么问题 #1,有没有办法强制 ef.net 使用属性而不是字段? -
INotifyPropertyChanged的 ef.net 实现似乎存在缺陷。如果您在属性上调用 PropoertyChanged 事件,而不实际更改它,它会将实体标记为Modified,即使它可以轻松比较原始值和当前值。这禁止我们手动引发属性更改事件来控制 WPF 呈现。不知道如何解决这个问题,或者它是否可以解决,因为它只适用于这个跟踪策略。我愿意接受有关如何在不激怒 ef.net 的情况下通知 WPF 元素的任何建议。 - 确定对象的状态是相当复杂的操作,涉及
dbContext.Entry(entry).State,它存在于DataContext层次结构内的任何WPF 绑定之外。它使绑定状态几乎不可能(例如更改脏条目的背景或显示保存按钮等)。我们通过从处理INotify*实现并保留[NotMapped] bool IsDirty标志的NotifySetterObject基类继承我们所有的实体类来“解决”它。不用说,我非常不喜欢这样,保留两个未链接的州旗听起来像是一场等待发生的事故。我想知道您是否遇到过类似的问题,以及您是否设计了一个更好、更理智的解决方案。
EF.net 似乎从框架 ef.net 发生了重大变化,因为它只非常适合分离的上下文场景(如 asp.net)。我们是否在这里浪费时间试图将这双鞋穿在 wpf 上?我们是否应该专注于更适合现场环境的不同 OR 引擎?
【问题讨论】:
标签: wpf entity-framework ef-core-3.0 wpf-core wpf-core-3.0