silverlight – MVVM：提供服务以使用UI的特定部分？

概述让我们说在我的应用程序中,有一个用户界面来表示(地理)地图.它作为UserControl集成到应用程序中,并在其背后有视图模型. 现在,假设我想为我的应用程序的其他部分提供通用服务接口,以在地图上执行常见任务(缩放,平移等),而不用担心UI细节.我可以放弃直接引用viewmodel,但我很确定我会违反关注点分离原则,更不用说它会不太可测试. 所以问题很少： >首先实现此类服务(作为UI的中间链接) 让我们说在我的应用程序中,有一个用户界面来表示(地理)地图.它作为UserControl集成到应用程序中,并在其背后有视图模型.

现在,假设我想为我的应用程序的其他部分提供通用服务接口,以在地图上执行常见任务(缩放,平移等),而不用担心UI细节.我可以放弃直接引用viewmodel,但我很确定我会违反关注点分离原则,更不用说它会不太可测试.

所以问题很少：

>首先实现此类服务(作为UI的中间链接)是否有意义并且是否良好实践？
>由于服务直接在地图的viewmodel上运行,它应该是实现服务接口的viewmodel本身吗？
>服务接口是否适合提供事件(例如,除了提供更改地图比例的方法,还提供地图比例也发生变化的事件)？或者是否最好采用某种事件广播器(聚合器)机制将此类通知推送到服务接口之外？

在此先感谢您的帮助.

解决方法 每当您需要两个视图模型进行通信时(或类似的东西,例如想要在视图模型上调用命令而不是自己的命令的按钮),我发现的最佳实践是使用消息传递通道. (MVVM light具有Messenger类; Prism和Caliburn.Micro都有一个EventAggregator.)当实例化命令的目标(地图视图模型)时,它将在消息传递通道上注册特定命令.当实例化调用者(例如按钮)时,它可以通过同一个通道发送命令.这可以使您的组件松散耦合.来自消息传递通道的命令可以很容易地被模拟用于单元测试.它还为您开辟了其他途径,例如同时打开多个地图(只需使用不同的消息传递通道或某种令牌).

在你的情况下我会跳过整个服务界面.使用事件聚合器时,它并没有真正增加太多.根据代码库的大小和复杂程度,您可能希望保留它,以便描述可用于映射的命令,但只有在您拥有多个命令时才有意义.在这种情况下,服务将注册为消息传递通道上的命令的终点,然后必须将这些命令转发到地图视图模型. (参见？添加不多,似乎只会使事情变得复杂.)

略过事件.他们似乎没有添加任何东西.

总结

以上是内存溢出为你收集整理的silverlight – MVVM：提供服务以使用UI的特定部分？全部内容，希望文章能够帮你解决silverlight – MVVM：提供服务以使用UI的特定部分？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。