zle*_*eao 8 structure decouple viewmodel mvvmcross sphero-api
我正在迈出MvvmCross框架的第一步,我正在尝试在项目和类结构方面决定最佳方法.我现在最关心的是决定如何组织我的视图模型以便在它们之间共享数据,同时遵循mvvm指南.
我有一个关于视图和相应视图模型(主要和配置)的简单示例.主视图具有绑定到viewmodel中的属性的一些控件.配置视图使用户能够更改文本颜色,列表中的项目数等...当用户更改配置时,这应该反映在主视图中.
我的第一种方法是创建单独的视图和视图模型.但是,如何通知主视图配置已更改？我在Github/Slodge下看到了Sphero项目,我意识到视图模型可以直接引用其他视图.这样,每次配置更改时都很容易通知主视图.但这不是mvvm推荐的解耦视图模型的偏差吗？
我能否获得一些有关处理此类类结构的最佳方法的见解？
接近这种类结构的最佳方法
在我看来,"最好的方式"最重要的衡量标准是选择一种意味着你的应用程序有效的方式.
你看过的例子 - sphero ball control - 有独立视图模型(home,gangnam,about,sphero等)的例子,它有一些相互了解的视图模型的例子 - sphero视图模型它是子视图模型.
在这种特殊情况下,这些视图模型彼此了解的原因是因为它们都是单个显示的一部分 - 它们被设计为在单个网格,数据透视或选项卡式UI中放置在一起.为了帮助他们合作我通过IParent和IChild接口给了他们彼此的引用.
这不是mvvm推荐的解耦视图模型的偏差吗？
我承认这确实意味着设计没有完全解耦,如果我将来需要移动或重用那些子vm,那么我可能需要做一些代码重构 - 但是现在设计对我来说很有效如果我需要的话,我个人很高兴在将来进行重构.
我现在最关心的是决定如何组织我的视图模型以便在它们之间共享数据,同时遵循mvvm指导
如果您正在构建复合(选项卡式)视图,并且您不满意使用聚合视图模型(如sphero vm及其子视图),那么请不要.
我确信在使用一个大视图模型的sphero中可以实现相同的效果,使用通过信使进行通信的多个视图模型或使用通过一个或多个自定义服务进行通信的多个视图模型.
对于您给出的特定示例 - 配置和主视图,我认为这不符合选项卡式方案 - 我可能会使用信使编码 - 这将为我提供一种灵活的机制来广播和接收更改通知应用程序的各个部分.
但是,其他设计绝对可用且可行 - 例如,您可以轻松地要求视图模型在每次显示时刷新其配置(这样做需要挂钩到onnavigatedto,viewwillapear和视图中的resume调用).
综上所述: