Ath*_*ari 7 .net c# observablecollection mvvm service-layer
我在Internet上看到的WPF MVVM应用程序示例将VM视为与服务层交互的层,该服务层使用来自外部库的"旧"事件,或使用HTTP或其他任何方式与Web交互.但是如果我自己构建所有M,V,VM,服务和其他部分呢？如何正确构建服务层和viewmodel层之间的交互？我可以直接ObservableCollection<OrderModel>进入服务并从视图的视图模型返回它,或者它被认为是一种不好的方法,还有更好的选择吗？
你可以这样做 - 当然可以.做这种事情的主要原因是减少多个WPF应用程序之间的重复.
但是,在某些情况下,您可能遇到的挑战(取决于您的服务层/数据层实现)是长期运行的服务,而这些服务又使用数据库连接.从使服务层自动同步应用程序对数据存储所做的更改的观点来看,ObservableCollections是诱人的; 但是,当您想要传达源自数据本身的更改时(即响应创建/修改数据的其他进程),它会变得复杂.
服务层实际上不能替换实例(即在大规模更改的情况下),因为它不再是引用的唯一所有者 - 但即使它可以,更换实例也会破坏任何绑定UI必须集合.
因此,您坚持尝试使一个实例保持最新状态.如果您的服务绑定到数据库,那么除非您在服务中编写某种形式的长时间运行的监视进程,否则在抛出ObservableCollection后保持最新的唯一简单方法是保存数据库连接/上下文(在Linq到Sql或EF的情况下)打开 - 因为否则相关对象等将无法检索(除非您强制所有对象一次性读取 - 这是不可扩展的).
好的,所以可以编写一些管理层来管理你的连接 - 但除了不可避免的轮询,或者你可能使用的SQL Server通知之外,我相信代码可能会变得非常复杂.
也就是说,它确实依赖 - 特定的问题是需要注意的问题,但可能是你有一个架构和环境,这些事情根本无关紧要.
我的建议,如果你想尝试一下 - 继续吧.为了我？我已经考虑过 - 除了将INotifyPropertyChanged添加到某些域模型之外,我坚持认为应用程序拥有自己的VM.多个应用程序可能共享同一个VM - 但这不是服务层本身的内部.
服务层以通常的一次性方式提供对数据和业务逻辑的访问.VM模式中的类旨在具有更长的生命周期 - 并且尝试编写长时间运行的服务层是非常困难的 - 特别是如果您希望它尝试解决所有未来应用程序可能出现的所有问题.不可避免地,您最终只能为单个应用程序在服务层内编写服务或VM类型 - 在这种情况下,它可能也会进入该App的代码库.
| 归档时间： |
|
| 查看次数： |
2270 次 |
| 最近记录： |