zoukankan      html  css  js  c++  java
  • Resource文件的相互引用与合并问题及其解决方案

     我们都知道在WPF中,所有的控件都有Resources属性,里面可以放Resource。一般比较常用的Resource位置就是ApplicationResource和各个WindowResource。那么这两个Resource的位置,除了作用范围不同之外,还有什么不同呢?

    一个不同点就是,ApplicationResource会被作用一个全局共享的Resource的来源。这会给Merge Resource Dictionary带来极大的方便,但是这个性质并不像想象中的那么好用。

     

    在实际项目中,通常会对Resource的使用有如下的几点要求。

    1.       不要把所有的Resource放在一个文件里。我们常常会把Resource按其功能或是使用对象,分别放置在不同的Resource Dictionary里,这样不仅结构清楚,找起来方便,而且用Blend打开时也会更快,共同开发的冲突也会更少。

    2.       使用Resource时,出于性能考虑,要尽量使用StaticResource。这个要求,会间接地要求Resource按顺序定义,就是说,未定义过的Resource是不能使用的。而XAML中又不存在类似C语言中的声明语句或是头文件。这样Resource就必须非常注意其顺序。一不小心就会出现NotFindException.

     

    当把上面的两个要求合并起来之后,问题会变得很复杂。由于Resource放在了不同的Resource文件中,这就要考虑到Resource的跨文件引用问题。这个问题有两个解决方案。

    1.       如果Resource文件A,使用了Resource文件B中的Resource,那么就在文件A中,通过ResourceDictionary.MergedResourceDictionariesResource文件B合并过来。这个方式的一个问题就是,要为每个文件维护一个依赖文件列表,而且如果有多个Resource文件Merge了同一个Resource文件,会给人一种冗余的感觉。是不是这个被Merge了多次的Resource文件,相当于有了多件拷贝?

    2.       另一种方式就是在ApplicationResource中把所有的Resource文件都Merge进来。而且要一个一个Merge。这样,下面的MergedResource就可以访问上面的MergedResource里的东西了。而且只有直接在ApplicationResource里这样写才有效果。

     

    MergeResource的示例如下。用代码会更直观一些。

     

    View Code
    1 <ResourceDictionary>
    2     <ResourceDictionary.MergedDictionaries>
    3         <ResourceDictionary Source="CommonProperties.xaml"/>
    4         <ResourceDictionary Source="Button.Style.xaml"/>
    5         <ResourceDictionary Source="ComboBox.Style.xaml"/>
    6     </ResourceDictionary.MergedDictionaries>
    7 </ResourceDictionary>

     

    在上面的示例中,如果XXXX.Style.xaml中的ResourceStatic的方式使用了CommonProperties.xaml里的Resource有如下图所示的引用关系。

     

    图1. Resource间的引用关系示例

     

    那么这样的Merge Resource方式,能否保证XXXX.Style.xaml能够引用到CommonProperties.xaml里的Resource呢?答案是不一定,要看这个MergeResource的代码放置在了什么地方,如果是在App.xaml里,可以;如果不是,则不可以。

     

    如下图所示。

     

    2. 可行的Merge方式(直接在ApplicationResourceMerge

     

    3. 不可行的Merge方式。(在单独的一个文件里Merge

     

    4. 亦不可行的方案(在WindowMerge

     

    所以在WPF程序中,应该尽量在App.xaml进行ResourceMerge工作。但是这也造成了一些问题。如DLL封装性的问题——专门存放ResourceDLL,不能通过一个已经Merge好的,单一的Resource文件把这个DLL里的所有Resource暴露给使用者,使用者必须在App.xaml里一个一个地引用DLL中的所有Resource文件,DLL改了,App.xaml的引用也要改,从而破坏了封装性。再一个问题就是如果没有WPF Application(比如在WinForm程序中集成一些WPF的组件),那就可能会没有Application级的Resource,也就没有很好的Merge Resource的解决方案了。可行的方案有四个。

    1.       建立一个WPF Application,并Host原来程序中的WinForm部分。而不是在WinForm程序里Host WPF组件。

    2.       把所有Resource放在一个文件里,并维护好Resource的前后顺序,这样就没有了文件间的引用问题。

    3.       为每个Resource文件都使用MergedResourceDictionary。把它用到的Resource文件Merge进来。这个方案可能会造成Resource重复的问题。

    4.       退一步。对于文件间的引用使用DynamicResource。有人认为DynamicResourceStaticResource的性能差,我同意。经过测试,DynamicResource用的时间是StaitcResource的5倍。但是如果Resource不会变,那只不过是在第一次加载时慢些罢了。还是在真正有性能问题的地方下功夫吧。

     

    这个只能在ApplicationMerge Resource File的事实,也许可以算是一个Bug吧,因为从WPF的使用者的角度而言,总是希望无论这个Merge在什么地方,都可以保证Resource文件的向上引用才好。

     

  • 相关阅读:
    用Java开发第一个APP
    去除字符串空格并竖向排列
    并发容器 concurrentHashMap--1.7 更改
    java并发容器CopyOnWriteArrayList 使用场景和内部实现分析
    java非并发容器ArrayList 和 LinkedList 优缺点比较及其实现源码分析
    并发容器之CopyOnWriteArrayList分析
    单例模式
    [Android]知识总结一:Activity
    阿里巴巴fastjson的使用问题
    java跨域请求的方式
  • 原文地址:https://www.cnblogs.com/loyung/p/3043062.html
Copyright © 2011-2022 走看看