资源字典与用户控件在组织大型 xaml 文件方面有何优缺点?
我知道有很多问题表明资源字典和用户控件都可以用于分解和组织大型 xaml 文件,但它们似乎都没有讨论使用 on 相对于另一个文件的优缺点。
我的问题是使用资源字典与用户控件来组织大型 xaml 文件有何优缺点?
I know there are a number of questions stating that both Resource Dictionaries and User Controls can be used to break up and organize large xaml files, but none of them seem to go into the pros and cons of using on over the other.
My question is what are the pros and cons of using Resource Dictionaries versus User Controls for organizing large xaml files?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在您想要封装行为的地方使用 UserControl(或自定义控件)。我所说的行为不仅指交互逻辑(例如具有自定义双击行为的列表框),还指数据模型(例如显示 Person 详细信息的控件),因此需要 PersonToDisplay 属性。特定于该 UserControl 的资源将放入控件的资源字典中。
在您想要共享资源的地方使用 ResourceDictionary。例如,如果您有一组画笔想要在多个位置使用(并且想要有一个中心位置来更新它们),那么这将是 ResourceDictionary 的候选者。
在某些情况下,可以纯粹使用资源来实现,但无论如何您可能希望将它们打包为控件,以便在使用时更容易理解。例如,如果您有一个按钮,其样式设置为当鼠标悬停在其上时闪烁,您可能会觉得用户更容易编写(和阅读)
而不是比Use a UserControl (or custom control) where you want to encapsulate behaviour. By behaviour I mean not just interaction logic, such as a list box with customised double-click behaviour, but data model, such as a control which displays the details of a Person, and therefore needs a PersonToDisplay property. Resources specific to that UserControl would go in the control's Resources dictionary.
Use a ResourceDictionary where you want to share resources. For example, if you have a set of brushes that you want to use in multiple places (and want to have a central place to update them), that would be a candidate for a ResourceDictionary.
There are cases that can be implemented purely with resources, but where you may want to package them up as a control anyway so that it's easier to understand at point of use. For example, if you have a button that is styled to flash when the mouse is over it, you may feel that it's easier for users to write (and read)
<local:AnnoyingButton />
rather than<Button Style="{StaticResource AnnoyingButton}" />
(where the style is in theAnnoyingButton.xaml
resource dictionary), even though the whole thing may actually be done with templates and triggers and no actual code. Here I would tend to err on the side of creating a control, because (a) it is more robust if I find I need to add code later on and (b) it saves me having to writeResourceDictionary.MergedDictionaries
elements. It's a judgment call though.我的经验法则:将 ResourceDictionaries 用于 DataTemplates、ControlTemplates、Style 和 ValueConverters、TemplateSelectors 等,以及 UserControls 将您的大视图(视觉元素)“切割”成多个部分,所有这些都使用您的 ResourceDictionaries 进行样式设置。
ResourceDictionaries 的问题在于,如果您将视觉元素放在那里,则只能使用它一次,因为它是在资源中实例化的,因此如果您使用,您会得到“视觉元素只能有一个父级”类型的异常在不同的视觉控制中它两次。另一方面,DataTemplates、Styles 和 ControlTemplates 作为工厂工作,因为许多控件可以同时使用它们 - 每个控件都有自己的实例化。 ValueConverters 和 TemplateSelectors(只是要注意改变它们内部的状态)可以被多个可视控件使用,因为它们本身不是可视的,这使得它们成为 ResourceDictionary 静态方法的完美候选者。
希望这能澄清一点。
My rule of thumb: Use ResourceDictionaries for DataTemplates,ControlTemplates,Style and ValueConverters, TemplateSelectors etc., and UserControls to 'cut' your large view (Visual elements) up into pieces, all of them using your ResourceDictionaries for styling.
The problem with ResourceDictionaries is that if you put a Visual Element in there, you can only use it once, as it is instantiated in the resources, so you get a "Visual Elements can only have one parent"-types of exceptions if you use it twice in different visual controls. DataTemplates, Styles and ControlTemplates on the other hand work as factories in that many Controls can use them simultaneously - each get their own instantiation. ValueConverters and TemplateSelectors (just be wary of changing state inside them) can be used by multiple visual controls since they are not visual themselves which makes them a perfect candidate for the static approach of a ResourceDictionary.
Hope this clears it up a bit.