我是 WPF 新手，我正在使用 Linq To Entities（和 SQLite 数据库）构建一个小应用程序。
我只是想知道，当属性发生更改时，我必须在哪里调用我的方法才能更新数据库？ 我会在 ViewModel 的属性中这样说：
public string FirstName
{
get
{
return this.person.FirstName;
}
set
{
this.person.FirstName = value;
OnPropertyChanged("FirstName");
this.person.updateFirstname(value);
}
}
我不确定这是否是最好的解决方案...
【问题讨论】：
标签： c# wpf data-binding mvvm
何时保存到数据库的问题导致Unit of Work pattern。 Linq-to-Entities 使用ObjectContext 对此进行了合理的实现，其中数据在上下文中排队，然后在逻辑工作单元完成时保存到数据库中。
在您的示例中，您已经在 L2E 实体 Person 上设置属性，该实体可能与上下文相关联。当您调用ObjectContext.SaveChanges 时，这将被保存而无需updateFirstname 方法。
您必须决定何时调用ObjectContext.SaveChanges（从而结束工作单元），并在用户显式保存或关闭表单时执行此操作（可选地提示用户提交或丢弃更改）在这里是一种合理的方法。为了实现这一点，您的视图模型引用 ObjectContext 并且可以在执行用户操作（通常使用 WPF ICommand published by the viewmodel and bound to the view 建模）时调用 SaveChanges 方法。
【讨论】：
Person，如果不使用 ObjectContext，您还能如何查询？
SaveChanges 以保留您对 Person 实体所做的更改。
ObjectContext.SaveChanges 将从他的 VM 中调用，因此 VM 将与包含他的 EF 模型的 DAL 紧密耦合？或者也许忘记 DAL 并在主项目中创建 EF 模型？无论项目规模如何，都看不出这怎么可能是个好主意...
您应该将更新集中在工作单元而不是单个字段上。如果您的数据库被正确规范化，每一行都将代表一个实体并且应该这样对待，对实体的更新应该使实体保持“有效”状态。在您的场景中，如果您更新人员的名字并打算在应用程序或服务器炸毁您的人员记录时也更新姓氏，那么您的人员记录将无效。
就 MVVM 而言，我通常要么搭载网格的“一次更新整行”策略并将该事件路由到视图模型中，要么我只是给他们一个保存按钮 :)
【讨论】：
最好将服务接口注入到您的 ViewModel 构造函数中，并使用某种类型的服务来更新数据库。 这样，您最终会得到松散耦合的系统，并且您的 ViewModel 应该不知道您的数据访问层......
【讨论】：