我在 Internet 上看到的 WPF MVVM 应用程序示例将 VM 视为与服务层交互的层，该服务层要么使用来自外部库的“旧”事件，要么使用 HTTP 或其他方式与 Web 交互。但是如果我自己构建所有的 M、V、VM、服务和其他部分呢？如何正确构建服务层和视图模型层之间的交互？我可以直接放入ObservableCollection<OrderModel>服务并从视图的视图模型中返回它，还是它被认为是一种不好的方法并且有更好的选择？
问问题
2699 次
3 回答
6
You can do this - of course you can. The primary reason to do such a thing would be to reduce duplication across multiple WPF applications.
However, a challenge you might have in some scenarios, depending on your service layer/data layer implementation, is long-running services that in turn use database connections. ObservableCollections are enticing from the point of view of having the service layer automatically synchronising changes made by an application to a data store; however it gets complicated when you want to communicate changes that originate from the data itself (i.e. in response to some other process that creates/modifies data).
The service layer can't really replace the instance (i.e. in the case of large-scale changes), since it is no longer the sole owner of the reference - but even if it could, replacing the instance would pretty much break any binding the UI has to the collection.
So you stick to trying to keep the one instance up to date. If your services are bound to a database, then unless you code-up some form of long-running monitoring process within your service, the only simple way to keep an ObservableCollection up to date after it's been dished out would be to hold database connections/contexts (in the case of Linq to Sql or EF) open - because otherwise related objects etc are not going to be able to retrievable (unless you force all objects to be read in one go - which is not scalable).
Okay, so it's possible to write some form of management layer which can manage the connections for you - but in addition to the inevitable polling, or perhaps SQL Server notifications that you might use, I believe the code might get quite complicated.
That said, it really does depend - that particular issue is one to look out for, but it might be that you have an architecture and environment in which such things simply don't matter.
My advice, if you want to try it - go ahead. For me? I've thought about it - and beyond adding INotifyPropertyChanged to some domain models, I stick to the idea that an application has it's own VM. Multiple applications might share the same VM - but that won't be internal to the service layer itself.
A service layer provides access to data and business logic in a typically one-shot way. Classes in the VM pattern are intended to have a much longer lifespan - and trying to code a long-running service layer is notoriously very hard to do - especially if you want it to try and solve all the problems that all future applications might present. Inevitably you will end up coding services or VM types within the service layer for a single application only - in which case it might as well have gone in that App's codebase.
于 2012-12-12T12:01:42.237 回答
2
我很想只从“可观察”方面相关的点使用 ObservableCollection，这通常是 VM 向 V 暴露一些东西。在堆栈的更下方（即 M）我很想坚持使用更通用的东西，比如列表和集合（除非你特别需要其他东西）。在任何情况下，VM 都可以轻松地基于任何旧的 IEnumerable 创建 ObservableCollection。
不过，这是一个合理的问题，尤其是 ObservableCollection 在 System.Collections 命名空间中的位置似乎表明 Microsoft 并不特别认为这是一个专门的类（当然也不是 wpf 特定的）。
于 2012-12-12T12:23:57.247 回答
0
出于多种原因，我不会这样做。它们在此处记录：可观察集合的常见错误
作者经历了人们在使用它们时犯的几个错误，包括在服务层中使用它们。
于 2012-12-12T11:58:39.033 回答