将模型列表公开给多个ViewModel - 并使它们保持同步

时间:2010-11-07 18:38:10

标签: silverlight windows-phone-7 mvvm-light

我知道有很多关于应该如何处理Model和ViewModel集合的讨论,以及BLINQ,CLINQ,MVVM Wrapper Kit等不同方提出了很多“syncher”解决方案。我仍然没有抓住这个,我想找到一个很好的解决方案,解决我目前项目中描述的问题。主要区别在于我有几个ViewModel公开了相同的Model数据。

我有一个相当简单的WP7项目,我使用MVVM Light和Messenger类作为中介。有一个从隔离存储中获取的项目列表。几个(四个)不同的视图以不同的形式显示这些数据。所有这三个都可以以不同的方式修改数据(ViewModel包含更改的逻辑 - 而不是视图)。

如果我使用ObservableCollection<>在包含List<>的ViewModel中在模型中,然后更改数据的ViewModel修改它自己的ObservableCollection<>和列表<>在模型中。如果我有一个ViewModel从模型中公开List,那么这可能就是我要做的事情,这样ViewModel就可以保持自己和模型的最新状态。但是,在这个项目中,我有几个消费者来到同一个List和ObservableCollections<>在其他ViewModels中不会过时。为了解决这种情况,我可以使用中介模式并通知其他ViewModel项目集合已更改,以便他们可以刷新它。我可以通过发送描述更改的消息来获得一些性能,并且所有其他ViewModel可以在内部执行相同的更改。但是,这需要我在一个中心位置共享一些逻辑,以避免在几个不同的ViewModel中重复添加/删除/更改逻辑。

由于我需要将更改传达给其他ViewModel,因此我决定采用另一种方式。我更改了ObservableCollection<>到标准列表<>并删除了处理更改通知的代码。因此,ViewModel和Model都具有List<>对象。如果我将模型列表包装在ViewModel中并不重要,我可以直接在ViewModel中公开Model.Items以简化事情(并且可能获得一些性能)。现在,当某些ViewModel更改某些内容时,它会直接在模型中更改它,然后发送一条消息,表明items集合已更改,并且所有ViewModel都会在集合属性上引发更改的属性通知。

这似乎工作正常。我有两个问题:

  • 这是一个很好的解决方案还是以后会遇到问题?我是否完全反对MVVM,从长远来看会损害代码库?
  • 我觉得变更通知有时会有点慢。那是当我“点击”列表中的项目时,在更新列表之前会有一个小延迟。我不确定这是不是因为我在几个视图中刷新了整个i列表,或者因为调解器延迟了。

非常感谢任何想法/评论。

2 个答案:

答案 0 :(得分:1)

跟踪不同的视图模型通过更改通知彼此将导致意大利面条代码。我目前正在使用一个复杂的Silverlight 4桌面应用程序。

我找到的解决方案是拥有一个单独的ViewModel,它包含将在其他ViewModel之间共享的数据。这样,您只有一个ObservableCollection - 一个与您的数据一起驻留在视图模型中的。

答案 1 :(得分:0)

在这种情况下做什么的部分决定将取决于列表中的对象数量以及您对它们进行的操作量。无论采用哪种方法,都要确保在真实设备上进行彻底测试以验证性能。

那就是说,我解决你的问题的倾向是采取你采取的方法:
- 它的简单性使其在未来具有灵活性 - 由于它的简单性,其他开发人员应该能够在将来更容易地理解代码。

正如我之前所说,验证真实设备上的性能以确认是否存在问题。如果这是一个问题,那么在重新架构应用程序之前,先看看隔离瓶颈并解决它。

相关问题