我应该在哪里定义我的数据模板?

12

我正在尝试找到在MVVM中将Views和ViewModels最佳耦合的方法,我选择了使用类型化DataTemplates的ViewModel-first方法,如这篇文章这个答案所描述的。我正在使用Prism并且有多个模块,每个模块都有自己的项目/类库。

我的问题是:我的DataTemplates应该放在哪个位置?

  1. 我应该将DataTemplates放在与其渲染的类型/ViewModels相同的项目中的Resource Dictionary中吗?
  2. 我应该将DataTemplates放在具有应用程序MainWindow(即Shell.xaml)的项目中的Resource Dictionary中吗?
  3. 这些Resource Dictionaries应该添加到App.Current.MainWindow.Resources.MergedDictionaries中吗?

希望这提供了足够的信息来描述我的问题。

更新:请参考所选答案的评论。

3个回答

2

更新以更加清晰地解释。

如果您的DataTemplate是通用的:

例如,您有一个UserControl绑定到ViewModel,该ViewModel具有BaseViewModel,该ViewModel公开某些属性。 您的DataTemplate显示这些属性。 因此,您可以在实现BaseViewModel的每个ViewModel上使用此DataTemplate。

最好将其放入App.xaml中,这样您就可以使用Key将其提取出来并应用于项目中的不同位置。

但是,如果您的DataTemplate非常特定:

例如,有一个UserControl仅绑定到ViewModel中指定的属性,并且您知道没有其他控件将绑定到该ViewModel,那么您将希望将其放入相同Xaml文件的Resources或定义UserControl的位置。


我知道可以使用DataTemplates来自定义在ListBox中显示数据的方式,并且可以通过引用其x:Key将此DataTemplate重复使用并应用于多个ListBoxes。但是根据Josh Smith的文章(见上文),我相信我也可以使用类型化DataTemplates将视图/用户控件与ViewModel耦合。也就是说,如果我向ListBox添加一个ViewModel对象,WPF将使用DataTemplate中指定的用户控件呈现ViewModel(而不是使用ToString())。我理解得对吗? - Blake Mumford
@Angavar 是的,你也可以使用类型化的DataTemplate来应用它。我只是举了一个例子,说明如何使用它们的x:Key来提取模板、样式等。 - King Chan

2

我相信在这里最好的方法是使用Themes\Generic.xaml资源文件。这个文件(应该确切地位于Themes文件夹中,名称为Generic.xaml)由WPF/Silverlight主题引擎使用,并包含整个应用程序共享的资源。您还可以在Themes文件夹中创建一个名为Generic.DataTemplates.xaml的单独文件,并从Generic.xaml中添加链接。Google对generic.xaml知道很多,或者您可以在我的答案中查看更多细节:WPF Prism - Where to put Resources?


嘿,谢谢你的建议。我有一段时间前阅读了那篇文章,并使用Rachel在那里描述的方法。我有一个基础设施项目,其中包含一个主题文件夹,我在其中使用“资源字典”存储我的样式。问题是,所有其他项目/模块都引用了这个基础设施项目。为了使用类型化的“数据模板”,我需要引用包含我的ViewModels的项目,这意味着创建循环依赖关系。我应该创建一个单独的项目来保存只有“数据模板”吗? - Blake Mumford
1
我认为你可以在模块的程序集中创建一个名为“Themes”的文件夹。在当前项目中,我就是这样做的——我在单独的UI程序集中共享模板,几乎每个模块的程序集都有自己的“Themes”文件夹。 - chopikadze
好的,听起来是个好办法!谢谢,我很感激你的建议。我会试着让它工作的。 - Blake Mumford
太好了!我采纳了您的建议,现在程序运行得非常好。我将 DataTemplates 定义为模块程序集中的资源字典,然后将该资源字典添加到 App.Current.MainWindow.Resources.MergedDictionaries 中的合并资源字典中。感谢您的时间 :) - Blake Mumford

0
根据Microsoft的App Studio,DataTemplates应该存储在Views目录下的DataTemplates子目录中。通用应用程序针对Windows UI和Windows Phone UI都有此目录,因此它不在共享项目中,因为它们不相同。不要使用Converge PRISM架构。它的设计完全错误!这不是针对Windows和Windows Phone架构而编写的,但正如他们所说的"收敛"。它应该像 Microsoft's App Studio 中的工作一样重新设计。不要寻找依赖注入,因为它没有也不需要。大多数使用依赖注入来模拟或伪造接口。设计数据的DataContext现在能够很好地与json数据配合使用,使用依赖注入的组件只会过度繁琐。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接