hel*_*ker 5 wpf observablecollection mvvm repository-pattern
我的桌面 WPF 应用程序有一个存储库（类型为Person），它驻留在模型层中，并由具有数据PersonList绑定到DataGrid.
当我打开我的应用程序时，默认情况下会显示该列表。在初始化期间，以下代码适用：
public class PersonScreenViewModel : ViewModelBase
{
PersonRepository _person_repository;
public ObservableCollection<Person> PersonList { get; set; }
public PersonScreenViewModel() {
_repositorio_pacientes = new RepositorioPacientes();
PersonList = new ObservableCollection<Person>(_person_repository.GetAll());
}
// ... ///
}
我的怀疑是基于理解如何实现“保存/更新”方法的一些困难。
关于 Repository 模式的每个文本都告诉我们“存储库应该表现得像一个 [实体 | 域对象] 的集合”。因此，最合乎逻辑的做法是将存储库本身数据绑定到DataGrid. 如果我创建了一个继承ObservableCollection并实现存储库逻辑的类，就可以做到这一点。目前，我所做的是获取存储库项目的副本，使用_repo.GetAll()，并在该副本中工作，必须在我的更改完成后提交回来。
具体来说，我的工作流程涉及在 DataGrid 中选择一行，更改所选对象的某些属性，并提交这些更改，期望使用新属性值持久保存相同的对象。
通常，如果您获取集合中的对象并对其进行修改，则不需要“更新”任何内容，因为您已经更改了对象本身。
问题是：“我如何将数据绑定到存储库本身？存储库是否应该继承自ObservableCollection？它应该如何完成？我的推理的某些部分是否有缺陷？”
重要的是，我的应用程序不是面向数据的，Person类非常基础（POCO 标记为[Serializable]，具有一些属性），并且我的存储库使用纯 XML 序列化和文件系统结构。
谢谢阅读！
在我个人看来，您当前所做的事情是正确的……在应用程序的各个层之间进行某种分离通常是一种很好的做法；模型、视图模型、视图和数据访问（有时合并为模型）。话虽如此，这实际上取决于您的应用程序......在小型应用程序上这样做可能不值得，因为它增加了大量的代码和设置和维护的时间。
然而，提供这种分离（称为关注点分离）的主要原因是使单元测试能够测试各个层而不涉及其他层。例如，如果我们想为视图模型编写单元测试，我们不想在数据库中的实际数据对象上测试它们的功能。如果我们有这种分离（通过使用接口），那么我们可以简单地模拟数据对象以在这些测试期间使用。
另一个原因（尽管在实践中不太常见）是允许“交换”整个层而不影响其他层中的代码。此类示例包括更改应用程序中使用的数据库，或者可能将视图从桌面应用程序更改为 Web 应用程序中的网页。如果我们有单独的层，那么这些更改不会影响其他层。
因此，为了直接回答你的问题，我根本不会将你的观点与存储库绑定......保持你当前的分离。毕竟，将来自数据库的集合复制到视图集合属性需要多长时间？
更新>>>
我不确定我是否完全理解您评论中的问题。我猜测您正在将PersonList视图模型中的属性绑定到DataGrid.ItemsSource显示数据的属性。中所做的任何更改都DataGrid应该影响您的 中的项目PersonList。如果您要添加“保存” Button，则可以在该单击或命令处理程序中更新数据库。
如果您想了解如何找出哪些元素已更改，可以使用多种方法来完成此操作。在如何从 WPF 数据网格中仅获取修改的项目中有一个很好的提示，但我更喜欢使用重复的集合，然后比较它们以查找更改的元素（您需要实现此Equals方法才能工作） ）。
如果这不能回答您的问题，请告诉我。