wpf - 在大型项目和 MVVM 中使用 Microsoft(或其他)功能区

Question

我们的应用程序是一个包含许多模块和 View 的大型项目。主窗口中有一个功能区，我们正在寻找将功能区集成到应用程序中的最佳方式。

我创建了一个服务，其中 View 可以注册模块以添加与其相关的功能区项目，此外，任何主视图实例都可以提供与该实例相关的自己的功能区项目。 RibbonItem 是一个小类，它抽象了功能区项的选项，主要有 Title、Description、Command、UIType 和 ChildItems。该服务负责在主视图更改时重建功能区。

我的一位同事认为这是不好的 MVVM，因为用户需要在 C# 代码中而不是在 XAML 中设计功能区 View ，他还说以这种方式很难同时禁用或启用一组项目，因为这些项目的每个命令都需要单独更新其 CanExecute。相反，他建议有一个主要的 Ribbon View 和 ViewModel 文件，每个想要为其模块或 View 添加功能区按钮的开发人员都需要在 View XAML 中添加它们，并在 ViewModel 中添加相关命令。此外，VisualStates 将用于根据 ViewModel 中的更改(例如 View 更改或选择更改)来确定将显示或启用哪些项目。我真的不喜欢这个解决方案，主要是因为所有开发人员都必须将他们的模块知识放在一个大文件中。

请注意，功能区中的某些项目(例如选项、退出)对整个应用程序是通用的，而有些与特定应用程序域相关，而有些仅与特定 View 相关。

编辑:我想我的主要问题是允许多个开发团队在单个功能区上集成的推荐方法是什么？我们是否应该有一个 RibbonView 和单个 RibbonViewModel 将包含功能区中所有可能的项目，并且每个团队将其项目添加到这些 V/VM 并定义何时显示它们的逻辑(可能通过使用视觉状态) ?或者我们是否允许每个 View 、 View 模型或模块针对服务注册功能区项目(在它们自己的 C# 代码中)，然后当事件 View 随所有注册到该类型的项目发生变化时，让服务根据需要渲染功能区？或者有没有更好的方法来实现这种集成？

你怎么看？
对于如何管理多个开发人员共有的单个功能区资源，您有更好的想法或意见吗？

谢谢，
split 者

Answer 1

我同意 Will 的评论，您的 View 模型不应该关心或知道它是如何渲染的，或者设计师是否决定改变它的渲染方式。

View 模型 应该只包含所有必需的信息让表示层渲染它。

所以 ViewModel 应该具有 Ribbon bar 需要绑定(bind)到的所有属性才能运行。然后，您可以使用 Resources.xaml 或其他一些策略来呈现它。

在黑暗中拍摄我会为 ViewModels 尝试这样的事情:

public interface IMenuViewModel : INotifyPropertyChanged
{
  ICommand Command {get;}
  string Title {get;}
  string Description {get;}
  UIType Type {get;}
  IList<IMenuViewModel> ChildItems {get;}
}

然后我可能会创建一个提供实现的抽象类 INotifyPropertyChanged使用集合类实现 INotifyCollectionChanged照顾管道代码。

然后我可能会在 Resources.xaml 中做这样的事情

<DataTemplate DataType="{x:Type vm:IMenuViewModel}">
  <StackPanel>
    <Button Command="{Binding Command}" Content="{Binding Type}"/>
    <ItemsControl ItemsSource="{Binding ChildItems}"/>
  </StackPanel>
</DataTemplate>

为您的 View 模型提供默认 View

然后有人要做的就是在您的功能区栏中创建一个条目

1) 实现 IMenuViewModel

2)如果他们希望他们的小部件以不同的方式呈现，可以选择在您的 resources.xaml 中添加另一个 DataTemplate 条目，如下所示:

<DataTemplate DataType="{x:Type vm:FooViewModel}">
    <v:FooView />
</DataTemplate>

我希望我没有深入研究我将如何实现。

要点是 ViewModel应该只公开 View 完成其工作所需的属性(呈现 ViewModel )，而不是 ViewModel做这项工作或关心它是如何完成的。