因此,我们将一个旧的 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 使用属性而不是字段? - ef.net 的实现
INotifyPropertyChanged
似乎有缺陷。如果您在属性上调用 PropoertyChanged 事件,而不实际更改它,它会将实体标记为Modified
,即使它可以轻松比较原始值和当前值。这禁止我们手动引发属性更改事件来控制 WPF 呈现。不知道如何解决这个问题,或者它是否可以解决,因为它只适用于这个跟踪策略。我愿意接受任何关于如何在不激怒 ef.net 的情况下通知 WPF 元素的建议。 - 确定对象的状态是相当复杂的操作,涉及的操作
dbContext.Entry(entry).State
存在于DataContext
层次结构内的任何 WPF 绑定之外。它使绑定状态几乎不可能(例如更改脏条目的背景或显示保存按钮等)。NotifySetterObject
我们通过从处理INotify*
实现并保留[NotMapped] bool IsDirty
标志的基类继承我们所有的实体类来“解决”它。不用说,我非常不喜欢这样,保留两个未链接的州旗听起来像是一场等待发生的事故。我想知道您是否遇到过类似的问题,以及您是否设计了一个更好、更理智的解决方案。
EF.net 似乎经历了从框架 ef.net 的重大变革转变,因为它只非常适合分离的上下文场景(如 asp.net)。我们是不是在浪费时间试图把这双鞋穿在 wpf 上?我们是否应该专注于更适合现场环境的不同 OR 引擎?