WPF MVVM应用程序的服务层中的ObservableCollection

Question

我在互联网上看到的WPF MVVM应用程序示例将VM视为与服务层交互的层，该服务层使用＆＃34; old＆＃34;来自外部库的事件，或使用HTTP或其他任何方式与Web交互。但是如果我自己构建所有M，V，VM，服务和其他部分呢？如何正确构建服务层和viewmodel层之间的交互？我可以将ObservableCollection<OrderModel>放入服务并按原样从视图模型中返回，还是认为它是一种糟糕的方法，还有更好的选择？

Answer 1

你可以这样做 - 当然可以。这样做的主要原因是减少多个WPF应用程序之间的重复。

但是，在某些情况下，根据您的服务层/数据层实现，您可能遇到的挑战是长期运行的服务，而这些服务又使用数据库连接。从使服务层自动同步应用程序对数据存储所做的更改的观点来看，ObservableCollections是诱人的;但是，当您想要传达源自数据本身的更改时（例如，响应创建/修改数据的其他进程），它会变得复杂。

服务层无法真正替换实例（即在大规模更改的情况下），因为它不再是引用的唯一所有者 - 但即使它可以，更换实例也会相当破坏UI对集合的任何绑定。

因此，您坚持尝试使一个实例保持最新状态。如果您的服务绑定到数据库，那么除非您在服务中编写某种形式的长时间运行的监视进程，否则在抛出ObservableCollection后保持最新的唯一简单方法是保存数据库连接/上下文（在Linq到Sql或EF的情况下）打开 - 因为否则相关的对象等将无法检索（除非你强制所有对象一次性读取 - 这是不可扩展的）。

好的，所以可以编写某种形式的管理层来管理你的连接 - 但除了不可避免的轮询，或者你可能使用的SQL Server通知之外，我相信代码可能会变得非常复杂。

尽管如此，它确实依赖于 - 特别的问题是需要注意的问题，但可能是你有一个架构和环境，这些事情根本无关紧要。

我的建议，如果你想尝试一下 - 继续吧。为了我？我已经考虑过 - 除了将INotifyPropertyChanged添加到某些域模型之外，我坚持认为应用程序拥有自己的VM。多个应用程序可能共享同一个VM - 但这不是服务层本身的内部。

服务层以通常的一次性方式提供对数据和业务逻辑的访问。 VM模式中的类旨在具有更长的生命周期 - 并且尝试编写长时间运行的服务层是非常困难的 - 特别是如果您希望它尝试解决所有未来应用程序可能存在的所有问题。不可避免地，您最终只能为单个应用程序在服务层内编写服务或VM类型 - 在这种情况下，它可能也会进入该应用程序的代码库。

Answer 2

我只想从“可观察”方面相关的点开始使用ObservableCollection，这通常是VM向V公开的东西。继续向下堆栈（即M）我会是试图坚持使用列表和集合等更通用的东西（除非你特别需要其他东西）。在任何情况下，VM都可以很容易地根据任何旧的IEnumerable创建一个ObservableCollection。

一个合理的问题，尤其是ObservableCollection在System.Collections命名空间中的位置似乎表明微软并没有特别认为这是一个专门的类（当然也不是特定于wpf）。

Answer 3

出于多种原因，我不这样做。他们在此处记录：Common mistakes with an observable collection

作者经历了人们用它们犯的几个错误，包括在服务层使用它们。