博客园_家园

prism框架里module太多启动速度过慢

2011-11-21T06:55:00Z

一个基于prism框架desktop项目，总共有100多个module。程序启动的时候有几秒钟的delay。

用的DirectoryModuleCatalog类从本地目录中装载module的程序集。

附：DirectoryModuleCatalog装载部分源代码

//===================================================================================
// Microsoft patterns & practices
// Composite Application Guidance for Windows Presentation Foundation and Silverlight
//===================================================================================
// Copyright (c) Microsoft Corporation.  All rights reserved.
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY
// OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT
// LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
// FITNESS FOR A PARTICULAR PURPOSE.
//===================================================================================
// The example companies, organizations, products, domain names,
// e-mail addresses, logos, people, places, and events depicted
// herein are fictitious.  No association with any real company,
// organization, product, domain name, email address, logo, person,
// places, or events is intended or should be inferred.
//===================================================================================
using System;
using System.Collections.Generic;
using System.Globalization;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Security.Policy;
using Microsoft.Practices.Prism.Properties;

namespace Microsoft.Practices.Prism.Modularity
{
    /// <summary>
    /// Represets a catalog created from a directory on disk.
    /// </summary>
    /// <remarks>
    /// The directory catalog will scan the contents of a directory, locating classes that implement
    /// <see cref="IModule"/> and add them to the catalog based on contents in their associated <see cref="ModuleAttribute"/>.
    /// Assemblies are loaded into a new application domain with ReflectionOnlyLoad.  The application domain is destroyed
    /// once the assemblies have been discovered.
    ///
    /// The diretory catalog does not continue to monitor the directory after it has created the initialze catalog.
    /// </remarks>
    public class DirectoryModuleCatalog : ModuleCatalog
    {
        /// <summary>
        /// Directory containing modules to search for.
        /// </summary>
        public string ModulePath { get; set; }

        /// <summary>
        /// Drives the main logic of building the child domain and searching for the assemblies.
        /// </summary>
        protected override void InnerLoad()
        {
            if (string.IsNullOrEmpty(this.ModulePath))
                throw new InvalidOperationException(Resources.ModulePathCannotBeNullOrEmpty);

            if (!Directory.Exists(this.ModulePath))
                throw new InvalidOperationException(
                    string.Format(CultureInfo.CurrentCulture, Resources.DirectoryNotFound, this.ModulePath));

            AppDomain childDomain = this.BuildChildDomain(AppDomain.CurrentDomain);

            try
            {
                List<string> loadedAssemblies = new List<string>();

                var assemblies = (
                                     from Assembly assembly in AppDomain.CurrentDomain.GetAssemblies()
                                     where !(assembly is System.Reflection.Emit.AssemblyBuilder)
                                        && assembly.GetType().FullName != "System.Reflection.Emit.InternalAssemblyBuilder"
                                        && !String.IsNullOrEmpty(assembly.Location)
                                     select assembly.Location
                                 );

                loadedAssemblies.AddRange(assemblies);

                Type loaderType = typeof(InnerModuleInfoLoader);

                if (loaderType.Assembly != null)
                {
                    var loader =
                        (InnerModuleInfoLoader)
                        childDomain.CreateInstanceFrom(loaderType.Assembly.Location, loaderType.FullName).Unwrap();
                    loader.LoadAssemblies(loadedAssemblies);
                    this.Items.AddRange(loader.GetModuleInfos(this.ModulePath));
                }
            }
            finally
            {
                AppDomain.Unload(childDomain);
            }
        }

        /// <summary>
        /// Creates a new child domain and copies the evidence from a parent domain.
        /// </summary>
        /// <param name="parentDomain">The parent domain.</param>
        /// <returns>The new child domain.</returns>
        /// <remarks>
        /// Grabs the <paramref name="parentDomain"/> evidence and uses it to construct the new
        /// <see cref="AppDomain"/> because in a ClickOnce execution environment, creating an
        /// <see cref="AppDomain"/> will by default pick up the partial trust environment of
        /// the AppLaunch.exe, which was the root executable. The AppLaunch.exe does a
        /// create domain and applies the evidence from the ClickOnce manifests to
        /// create the domain that the application is actually executing in. This will
        /// need to be Full Trust for Composite Application Library applications.
        /// </remarks>
        /// <exception cref="ArgumentNullException">An <see cref="ArgumentNullException"/> is thrown if <paramref name="parentDomain"/> is null.</exception>
        protected virtual AppDomain BuildChildDomain(AppDomain parentDomain)
        {
            if (parentDomain == null) throw new System.ArgumentNullException("parentDomain");

            Evidence evidence = new Evidence(parentDomain.Evidence);
            AppDomainSetup setup = parentDomain.SetupInformation;
            return AppDomain.CreateDomain("DiscoveryRegion", evidence, setup);
        }

        private class InnerModuleInfoLoader : MarshalByRefObject
        {
            [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", "CA1822:MarkMembersAsStatic")]
            internal ModuleInfo[] GetModuleInfos(string path)
            {
                DirectoryInfo directory = new DirectoryInfo(path);

                ResolveEventHandler resolveEventHandler =
                    delegate(object sender, ResolveEventArgs args) { return OnReflectionOnlyResolve(args, directory); };

                AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve += resolveEventHandler;

                Assembly moduleReflectionOnlyAssembly =
                    AppDomain.CurrentDomain.ReflectionOnlyGetAssemblies().First(
                        asm => asm.FullName == typeof(IModule).Assembly.FullName);
                Type IModuleType = moduleReflectionOnlyAssembly.GetType(typeof(IModule).FullName);

                IEnumerable<ModuleInfo> modules = GetNotAllreadyLoadedModuleInfos(directory, IModuleType);

                var array = modules.ToArray();
                AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve -= resolveEventHandler;
                return array;
            }

            private static IEnumerable<ModuleInfo> GetNotAllreadyLoadedModuleInfos(DirectoryInfo directory, Type IModuleType)
            {
                List<FileInfo> validAssemblies = new List<FileInfo>();
                Assembly[] alreadyLoadedAssemblies = AppDomain.CurrentDomain.ReflectionOnlyGetAssemblies();

                var fileInfos = directory.GetFiles("*.dll")
                    .Where(file => alreadyLoadedAssemblies
                                       .FirstOrDefault(
                                       assembly =>
                                       String.Compare(Path.GetFileName(assembly.Location), file.Name,
                                                      StringComparison.OrdinalIgnoreCase) == 0) == null);

                foreach (FileInfo fileInfo in fileInfos)
                {
                    Assembly assembly = null;
                    try
                    {
                        assembly = Assembly.ReflectionOnlyLoadFrom(fileInfo.FullName);
                        validAssemblies.Add(fileInfo);
                    }
                    catch (BadImageFormatException)
                    {
                        // skip non-.NET Dlls
                    }
                }

                return validAssemblies.SelectMany(file => Assembly.ReflectionOnlyLoadFrom(file.FullName)
                                            .GetExportedTypes()
                                            .Where(IModuleType.IsAssignableFrom)
                                            .Where(t => t != IModuleType)
                                            .Where(t => !t.IsAbstract)
                                            .Select(type => CreateModuleInfo(type)));
            }

            private static Assembly OnReflectionOnlyResolve(ResolveEventArgs args, DirectoryInfo directory)
            {
                Assembly loadedAssembly = AppDomain.CurrentDomain.ReflectionOnlyGetAssemblies().FirstOrDefault(
                    asm => string.Equals(asm.FullName, args.Name, StringComparison.OrdinalIgnoreCase));
                if (loadedAssembly != null)
                {
                    return loadedAssembly;
                }
                AssemblyName assemblyName = new AssemblyName(args.Name);
                string dependentAssemblyFilename = Path.Combine(directory.FullName, assemblyName.Name + ".dll");
                if (File.Exists(dependentAssemblyFilename))
                {
                    return Assembly.ReflectionOnlyLoadFrom(dependentAssemblyFilename);
                }
                return Assembly.ReflectionOnlyLoad(args.Name);
            }

            [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", "CA1822:MarkMembersAsStatic")]
            internal void LoadAssemblies(IEnumerable<string> assemblies)
            {
                foreach (string assemblyPath in assemblies)
                {
                    try
                    {
                        Assembly.ReflectionOnlyLoadFrom(assemblyPath);
                    }
                    catch (FileNotFoundException)
                    {
                        // Continue loading assemblies even if an assembly can not be loaded in the new AppDomain
                    }
                }
            }

            private static ModuleInfo CreateModuleInfo(Type type)
            {
                string moduleName = type.Name;
                List<string> dependsOn = new List<string>();
                bool onDemand = false;
                var moduleAttribute =
                    CustomAttributeData.GetCustomAttributes(type).FirstOrDefault(
                        cad => cad.Constructor.DeclaringType.FullName == typeof(ModuleAttribute).FullName);

                if (moduleAttribute != null)
                {
                    foreach (CustomAttributeNamedArgument argument in moduleAttribute.NamedArguments)
                    {
                        string argumentName = argument.MemberInfo.Name;
                        switch (argumentName)
                        {
                            case "ModuleName":
                                moduleName = (string) argument.TypedValue.Value;
                                break;

                            case "OnDemand":
                                onDemand = (bool) argument.TypedValue.Value;
                                break;

                            case "StartupLoaded":
                                onDemand = !((bool) argument.TypedValue.Value);
                                break;
                        }
                    }
                }

                var moduleDependencyAttributes =
                    CustomAttributeData.GetCustomAttributes(type).Where(
                        cad => cad.Constructor.DeclaringType.FullName == typeof(ModuleDependencyAttribute).FullName);

                foreach (CustomAttributeData cad in moduleDependencyAttributes)
                {
                    dependsOn.Add((string) cad.ConstructorArguments[0].Value);
                }

                ModuleInfo moduleInfo = new ModuleInfo(moduleName, type.AssemblyQualifiedName)
                                            {
                                                InitializationMode =
                                                    onDemand
                                                        ? InitializationMode.OnDemand
                                                        : InitializationMode.WhenAvailable,
                                                Ref = type.Assembly.CodeBase,
                                            };
                moduleInfo.DependsOn.AddRange(dependsOn);
                return moduleInfo;
            }
        }
    }
}

初步怀疑是在这里花费了太多的时间。

解决方式：

准备使用xaml文件来存储modules的配置信息。第一次启动程序当模块装载成功以后，创建一个xaml配置文件。

以后启动程序不再遍历目录，之间从xaml文件读取配置信息。

代码如下：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Practices.Prism.Modularity;
using System.IO;

namespace ModularityWithUnity.Desktop
{
    public class ModuleCatalogConfigXAML
    {
        private const string SPACE_STRING_4 = "    ";
        private const string SPACE_STRING_8 = "        ";
        private ModuleCatalog moduleCatalog;
        private StringBuilder sb;

        public ModuleCatalogConfigXAML(ModuleCatalog moduleCatalog)
        {
            sb = new StringBuilder();
            this.moduleCatalog = moduleCatalog;
        }

        public void GenerateXAMLConfigFile(string fileFullPath)
        {
            BuildHeader();
            BuildGroups();
            BuildByGroupless();
            BuildFooter();
            SaveAsFile(fileFullPath, sb.ToString());
        }

        private static void SaveAsFile(string savedPath, string content)
        {

            using (StreamWriter sw = File.CreateText(savedPath))
            {
                sw.Write(content);
            }
        }

        private void BuildHeader()
        {
            sb.AppendLine("<Modularity:ModuleCatalog xmlns=\"http://schemas.microsoft.com/winfx/2006/xaml/presentation\"");
            sb.AppendLine(SPACE_STRING_8 +"xmlns:x=\"http://schemas.microsoft.com/winfx/2006/xaml\"");
            sb.AppendLine(SPACE_STRING_8 + "xmlns:sys=\"clr-namespace:System;assembly=mscorlib\"");
            sb.AppendLine(SPACE_STRING_8 + "xmlns:Modularity=\"clr-namespace:Microsoft.Practices.Prism.Modularity;assembly=Microsoft.Practices.Prism\">");

        }

        private void BuildFooter()
        {
            sb.AppendLine("</Modularity:ModuleCatalog>");
        }

        private void BuildGroups()
        {
            foreach (var group in moduleCatalog.Groups)
            {
                BuildByGroup(group);
            }
        }

        private void BuildByGroup(ModuleInfoGroup group)
        {
            //IEnumerable<ModuleInfoGroup> groups = this.moduleCatalog.Groups;
            sb.AppendLine(SPACE_STRING_4 + "<Modularity:ModuleInfoGroup ");
            if (!string.IsNullOrEmpty(group.Ref))
            {
                sb.Append(" Ref=\"" + group.Ref + "\"");
            }

            sb.Append(" InitializationMode=\"" + group.InitializationMode.ToString() +"\">");
            IEnumerator<ModuleInfo> moduleInfos = group.GetEnumerator();

            while(moduleInfos.MoveNext())
            {
                BuildModule(moduleInfos.Current,SPACE_STRING_8);
            }
        }

        private void BuildByGroupless()
        {
            IEnumerable<ModuleInfo> groupLessModules = this.moduleCatalog.Items.OfType<ModuleInfo>();
            foreach (var moduleInfo in groupLessModules)
            {
                BuildModule( moduleInfo,SPACE_STRING_4);
            }
        }

        private void BuildModule(ModuleInfo moduleInfo,string space)
        {
            sb.AppendLine(space + "");

            string content = space + "<Modularity:ModuleInfo ";


            if (!string.IsNullOrEmpty(moduleInfo.Ref))
            {
                content += " Ref=\"" + moduleInfo.Ref + "\"";
            }

            if (!string.IsNullOrEmpty(moduleInfo.ModuleName))
            {
                content += " ModuleName=\"" + moduleInfo.ModuleName + "\"";
            }

            content += " ModuleType=\"" + moduleInfo.ModuleType + "\" >";

            sb.AppendLine(content);

            if (moduleInfo.DependsOn != null && moduleInfo.DependsOn.Count>0)
            {
                sb.AppendLine(space + SPACE_STRING_4 + "<Modularity:ModuleInfo.DependsOn>");
                foreach (var item in moduleInfo.DependsOn)
                {
                    sb.AppendLine(space + SPACE_STRING_4 + SPACE_STRING_4 + "<sys:String>" + item + "</sys:String>");
                }

                sb.AppendLine(space + SPACE_STRING_4 + "</Modularity:ModuleInfo.DependsOn>");
                sb.AppendLine(space + "</Modularity:ModuleInfo> ");
            }

            sb.AppendLine(space + "</Modularity:ModuleInfo> ");
                //sb.Append(" />");

        }
    }
}

使用的时候：

UnityBootstrapper

1.虚方法CreateModuleCatalog 用来返回ModuleCatalog类。
在此方法中添加逻辑如下：
如果modules的配置文件已经存在，则通过配置文件来生成ModuleCatalog.
2.虚方法InitializeModules装载模块信息，在此方法后调用GenerateXAMLConfigFile 生成模块配置文件。

本文链接

Localizing of WPF application

2011-11-21T06:11:00Z

The main WPF thread will always be assigned a default setting for CurrentCulture and CurrentUICulture. You can also explicitly set these values based on user preferences (to be discussed). An important point to note, however, is that if a WPF application spins up new threads, those threads will not inherit the main UI thread’s culture settings, in fact they will not be set at all! So, be sure to explicitly assign new threads with the appropriate values.

本文链接

Unity 中的拦截功能

2011-11-19T05:35:00Z

Dino Esposito

在上个月的专栏中，我简要介绍了 Unity 2.0 依赖关系注入容器使用的拦截机制。在演示面向方面的编程 (AOP) 的核心概念之后，我介绍了一个具体的拦截示例，可能符合如今的很多开发人员的需要。

您是否想要扩展现有代码的行为却不想以任何方式触及源代码？您是否希望围绕现有的代码再运行更多代码？

AOP 的目标是提供一种方法，将核心代码与其他干扰核心业务逻辑的内容隔离开。 Unity 2.0 提供基于 Microsoft .NET Framework 4 的框架来实现此目的，而且极其快速和方便。

为了使您完全理解这篇后续文章的目的，我先概要介绍上个月的内容。您会发现，在上个月的代码中，我作了一些假设并使用了一些默认组件。这个月我将回过头去更详细地讨论您通常会遇到的选择和选项。

Unity 中的 AOP

假设您已经部署了应用程序，以便在某个时刻执行一些与业务相关的操作。一天，您的客户要求扩展该行为，以便执行更多工作。您找出源代码，进行修改，然后按照编码和测试新功能所需的时间来收取咨询费用。但如果您能顺利添加新的行为而不用触及现有的源代码，岂不是更好？

考虑一下稍有不同的情况。首先，如果您并不是独立顾问而是全职公司员工，该怎么办呢？收到的更改请求越多，您就得在现有项目之外花费越多的时间；更糟糕的是，您还得面临为基本代码创建新分支（并不是必需的）的风险。因此，您会由衷地喜欢可以让您顺利添加新的行为却无需触及源代码的解决方案。

最后，假设有人报告了错误或严重的性能问题。您需要调查并修正问题，而且您希望它不会引人注意。在这种情况下，您同样期望能够顺利添加新的行为而不用触及源代码。

AOP 可以帮助您应对所有这些情况。

上个月，我演示了如何利用 Unity 2.0 中的拦截 API 围绕现有方法添加预处理和后处理代码，而不用触及该方法。但这段简短的演示利用了几个假设。

首先，它利用由 Unity 反转控制 (IoC) 基础结构注册的类型，并通过 Unity 工厂层进行实例化。

其次，联接点集合只是通过接口定义的。在 AOP 术语中，联接点集合代表目标类中的位置集合，而框架就在这些位置按需注入额外的行为。基于接口的联接点集合表示只有该接口的成员才会通过代码注入在运行时扩展。

第三，我主要关注支持拦截的配置设置，而没有考虑能够让您在代码中配置 Unity 的 Fluent API。

在本文的其余部分，我将探讨 Fluent API 以及定义 Unity 拦截功能的其他方法。

可拦截的实例

若要为现有的类实例或新创建的类实例添加新的行为，您必须对工厂有一定的控制力。换句话说，AOP 不是万能的，您不可能绑定通过标准的 new 运算符实例化的普通 CLR 类：

          var calculator = new Calculator();

AOP 框架控制实例的方式可能大有不同。在 Unity 中，您可以求助于某些返回原始对象代理的显式调用，或者让代码完全在 IoC 框架之后运行。为此，大多数 IoC 框架都提供 AOP 功能。 Spring.NET 和 Unity 就是两个示例。当 AOP 和 IoC 一起使用时，就会得到顺利、轻松和有效的编码体验。

我们先从一个示例开始，其中没有使用 IoC 功能。这里是一些基本代码，可以让现有的 Calculator 类实例变得可以拦截：

          var calculator = new Calculator();
var calculatorProxy = Intercept.ThroughProxy<ICalculator>(calculator,
  new InterfaceInterceptor(), new[] { new LogBehavior() });
Console.WriteLine(calculatorProxy.Sum(2, 2));

最后要处理一个包装了原始对象的可拦截代理。在这种情况下，我假设 Calculator 类实现 ICalculator 接口。若要变得可拦截，类必须实现接口或者继承自 MarshalByRefObject。如果类派生自 MarshalByRefObject，那么拦截程序的类型必须是 TransparentProxyInterceptor：

          var calculator = new Calculator();
var calculatorProxy = Intercept.ThroughProxy(calculator,
  new TransparentProxyInterceptor(), new[] { new LogBehavior() });
Console.WriteLine(calculatorProxy.Sum(2, 2));

Intercept 类还提供 NewInstance 方法，您可以调用该方法以更直接的方式创建可拦截的对象。以下就是使用方法：

          var calculatorProxy = Intercept.NewInstance<Calculator>(
  new VirtualMethodInterceptor(), new[] { new LogBehavior() });

请注意，当您使用 NewInstance 时，拦截程序组件必须稍有不同。它不能是 InterfaceInterceptor，也不能是 TransparentProxyInterceptor，而应该是 VirtualMethodInterceptor 对象。那么 Unity 中有多少种拦截程序？

实例和类型拦截程序

拦截程序是一种 Unity 组件，该组件负责捕获对目标对象的原始调用并通过行为管道进行路由，使得每个行为都有机会在常规方法调用之前或之后运行。拦截的类型有两种：实例拦截和类型拦截。

实例拦截程序创建代理以筛选针对所拦截实例的传入调用。类型拦截程序生成新的类（这个类派生自要拦截的类型），并处理该派生类型的实例。不用说，原始类型和派生类型的区别就在于用来筛选传入调用的逻辑。

对于实例拦截，应用程序代码首先使用传统的工厂（或 new 运算符）创建目标对象，然后强制通过 Unity 提供的代理与其交互。

对于类型拦截，应用程序通过 API 或 Unity 创建目标对象，然后处理该实例。（您无法使用 new 运算符直接创建对象并获得类型拦截。）但是目标对象不是原始类型。实际的类型由 Unity 实时派生，并且会加入拦截逻辑（请参见图 1）。

图 1 实例拦截程序和类型拦截程序

InterfaceInterceptor 和 TransparentProxyInterceptor 是两个 Unity 拦截程序，属于实例拦截程序类别。 VirtualMethodInterceptor 属于类型拦截程序类别。

InterfaceInterceptor 可以拦截目标对象上的一个接口的公共实例方法。该拦截程序可以应用到新的和现有的实例。

TransparentProxyInterceptor 可以拦截多个接口和按引用封送的对象上的公共实例方法。这是最慢的拦截方式，但可以拦截的方法最多。该拦截程序可以应用到新的和现有的实例。

VirtualMethodInterceptor 可以拦截公共和受保护的虚拟方法。该拦截程序只能应用到新的实例。

应该注意的是，实例拦截可以应用到任意公共的实例方法，但不能应用到构造函数。这在将拦截应用到现有实例时相当明显，而将拦截应用到新创建的实例时则不那么明显。实例拦截的实现方式是构造函数在应用程序代码取回要处理的对象时已经执行。结果，任何可拦截操作都必须在创建实例之后。

类型拦截使用动态代码生成来返回从原始类型继承的对象。在这种情况下，任何公共和受保护的虚拟方法都被重写，以便支持拦截。请考虑使用以下代码：

          var calculatorProxy = Intercept.NewInstance<Calculator>(
  new VirtualMethodInterceptor(), new[] { new LogBehavior() });

Calculator 类如下所示：


          public class Calculator {
  public virtual Int32 Sum(Int32 x, Int32 y) {
    return x + y;
  }
}

图 2 显示了对 calculatorProxy 变量进行动态检查后得到的类型的实际名称。

图 2 类型拦截之后的实际类型

另外还要注意实例拦截和类型拦截之间存在的其他显著区别，例如按照调用的对象拦截调用。使用类型拦截时，如果一个方法调用同一对象上的另一个方法，那么该自我调用就可以被拦截，因为拦截逻辑在同一个对象中。但是，对于实例拦截，则只有当调用通过代理进行时，才能发生拦截。当然，自我调用不需要经过代理，因此不会发生拦截。

使用 IoC 容器

在上个月的示例中，我使用了 Unity 库的 IoC 容器来完成对象的创建。 IoC 容器是围绕对象创建的一个额外层，可以增加应用程序的灵活性。如果您将 IoC 框架与更多 AOP 功能相结合，就更是如此。此外（我是这样认为的），如果您将 IoC 容器与离线配置结合使用，代码的灵活程度将超乎想象。但是，下面这个示例将使用 Unity 的容器以及基于代码的 Fluent 配置：

          // Configure the IoC container
var container = UnityStarter.Initialize();
 
// Start the application
var calculator = container.Resolve<ICalculator>();
var result = calculator.Sum(2, 2);

启动容器所需的代码可以隔离在不同的类中，并在应用程序启动时调用。启动代码将指导容器如何围绕应用程序解析类型以及如何处理拦截。调用 Resolve 方法可以为您屏蔽拦截的所有细节。 图 3 显示了启动代码可能的实现方式。

图 3 启动 Unity

          public class UnityStarter {
  public static UnityContainer Initialize() {
    var container = new UnityContainer();
 
    // Enable interception in the current container 
    container.AddNewExtension<Interception>();
 
    // Register ICalculator with the container and map it to 
    // an actual type.
          In addition, specify interception details.
          container.RegisterType<ICalculator, Calculator>(
      new Interceptor<VirtualMethodInterceptor>(),
      new InterceptionBehavior<LogBehavior>());
 
    return container;
  }
}

比较有利的一点是这段代码可以移动到独立的程序集中，动态加载或更改。更重要的是，您可以在一个位置配置 Unity。如果您坚持使用 Intercept 类（其行为就像智能工厂，每次使用时都需要做准备），就无法做到这一点。因此，如果您的应用程序需要 AOP，请务必通过 IoC 容器获得。如果将配置的详细信息移到 app.config 文件（如果是 Web 应用程序则是 web.config）中，就可以用更灵活的方式实现相同的解决方案。在这种情况下，启动代码包含以下两行：

          var container = new UnityContainer();
container.LoadConfiguration();

图 4 显示了配置文件中必须包含的脚本。在这里，我为 ICalculator 类型注册了两种行为。这表示对接口公共成员的所有调用都将由 LogBehavior 和 BinaryBehavior 进行预处理和后处理。

图 4 通过配置添加拦截细节

          <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
  <assembly name="SimplestWithConfigIoC"/>
  <namespace name="SimplestWithConfigIoC.Calc"/>
  <namespace name="SimplestWithConfigIoC.Behaviors"/>
 
  <sectionExtension 
    type="Microsoft.Practices.Unity.
          InterceptionExtension.Configuration.
          InterceptionConfigurationExtension,     
      Microsoft.Practices.Unity.Interception.Configuration" />
 
  <container>
    <extension type="Interception" />
 
    <register type="ICalculator" mapTo="Calculator">
      <interceptor type="InterfaceInterceptor"/>
      <interceptionBehavior type="LogBehavior"/>
      <interceptionBehavior type="BinaryBehavior"/>
    </register>
 
    <register type="LogBehavior">
    </register>
 
    <register type="BinaryBehavior">
    </register>
 
  </container>
</unity>

请注意，由于 LogBehavior 和 BinaryBehavior 是具体的类型，因此您实际上根本不需要注册它们。 Unity 的默认设置会自动处理它们。

行为

在 Unity 中，行为是真正实现横切关注点的对象。作为实现 IInterceptionBehavior 接口的类，行为将覆盖被拦截方法的执行循环，并且可以修改方法参数或返回值。行为甚至可以完全阻止方法被调用，或者多次调用方法。

一个行为由三个方法组成。 图 5 显示了一个拦截方法 Sum 并将返回值修改为二进制字符串的示例行为。方法 WillExecute 只是一种优化代理的方式。如果它返回 False，行为就不会执行。

图 5 行为示例

          public class BinaryBehavior : IInterceptionBehavior {
  public IEnumerable<Type> GetRequiredInterfaces() {
    return Type.EmptyTypes;
  }
 
  public bool WillExecute {
    get { return true; }
  }
 
  public IMethodReturn Invoke(
    IMethodInvocation input, 
    GetNextInterceptionBehaviorDelegate getNext) {
 
    // Perform the operation
    var methodReturn = getNext().Invoke(input, getNext);
 
    // Grab the output
    var result = methodReturn.ReturnValue;
 
    // Transform
    var binaryString = ((Int32)result).ToBinaryString();
 
    // For example, write it out
    Console.WriteLine("Rendering {0} as binary = {1}", 
      result, binaryString);
 
    return methodReturn;
  }
}

这其实有点微妙。 Invoke 总是被调用，因此即使返回 False，您的行为实际上也会执行。但是在创建代理或派生类型时，如果为该类型注册的所有行为都将 WillExecute 设置为 False，那么也就不会创建代理本身，您将再次处理原始对象。这实际上是在优化代理创建。

GetRequiredInterfaces 方法允许行为向目标对象添加新接口，从此方法返回的接口将添加到代理中。因此，行为的核心就是 Invoke 方法。该参数输入让您可以访问目标对象上正在调用的方法。参数 getNext 是一个委托，用于移动到管道中下一个行为，并且最终执行目标上的方法。

Invoke 方法确定调用目标对象上的公共方法时所用的实际逻辑。请注意，目标对象上所有被拦截的方法都将按照 Invoke 中表达的逻辑执行。

如果要使用更特殊的匹配规则，该怎么办呢？使用我在本文中介绍的普通拦截，您能做的就是运行一组 IF 语句，来找出被调用的是哪个方法，如下所示：

          if(input.MethodBase.Name == "Sum") {
  ...
          }

下个月我将继续这个话题，探讨以更有效的方式应用拦截，为被拦截的方法定义匹配规则。

本文链接

Interception and Interceptors in C# (Aspect oriented programming) 转载

2011-11-19T04:27:00Z

Interception and Interceptors in C# (Aspect oriented programming)

by Ioannis 16. January 2011 10:38

In this post, we see how to define specific actions to be executed before or after the execution of every call to a method in our code. This is also known as “intercepting” the execution of a method and is related to AOP (Aspect Oriented Programming). We will explore two different ways of achieving this:

Using Microsoft’s Unity framework
Using the PostSharp library

CastleDynamicProxy is another library allowing you to intercept methods and resembles a lot to the Unity framework’s approach so it will not be described here. You can also use .NET framewrok’s Emit namespace or CodeDom to create your intercepting Proxy objects from scratch but this approach is out of the scope of this post.

Aspect Oriented Programming deals with horizontal concerns in the specifications of your programs. Horizontal concerns are requirements that span through every business logic or specific behavior of your system. Take for example the following figure displaying some typical modules of an e-shop application.

The classes of the system that deal with the system’s business logic (charging, product browsing etc), in a good design, do not replicate logic within each other. Those are “Vertical concerns” since they can be considered unrelated. On the contrary, if we want to provide logging for every method in our classes or want to apply security checks we deal with “Horizontal concerns” since they span throughout all the modules of the system.

Now, if you imagine implementing the “typical” way those concerns (eg the logging mechanism), you will end up decorating a lot of your “Vertical concern classes” with code like the following:

Not very pretty especially if you image replicating this in every class of every “Vertical concern”. This is where Aspect Oriented Programming comes in handy by providing a way of turning those horizontal concerns into “Aspects” which practically means that you find a way of intercepting the execution of those methods adding the extra logic in a single place and thus perform your required actions with as few changes as possible to the initial code.

Microsoft’s Unity Framework (link)

Microsoft’s Unity 2.0 comes within Enterprise Library. It is easy to use with the limitation that you need to have all your objects to intercept created through a factory within your code and also the interceptable classes need to implement an Interface or derive from the MarshalByRefObject class.

So lets suppose you have the following class:

public class ClassToIntercept
{
    public int ID { get; set; }

    public int GetRandomNumber(int min, int max) {
        return new Random().Next(min,max);
    }
}

In your code all objects of this class are instantiated with “new ClassToIntercept()”. You have no way to intercept this with the Unity Framework without changing anything in the class or the object creation places. On the contrary if you have built factories for your classes (that is you never create objects with the new keyword but rather ask a method to create them for you – not a bad programming practice for many reasons) such as:

public static class ClassToInterceptFactory
{
    public static ClassToIntercept GetClassToIntercept()
    {
        ClassToIntercept ReturnClass = new ClassToIntercept();
        return ReturnClass;
    }
}

Now whenever you need a ClassToIntercept object in your code you call the GetClassToIntercept method. Unfortunately, you still cannot intercept the class methods. Your class also needs to derive from MarshalByRef object:

public class ClassToIntercept:MarshalByRefObject
{
    public int ID { get; set; }

    public int GetRandomNumber(int min, int max) {
        return new Random().Next(min,max);
    }
}

And now you can change your factory as follows:

public static ClassToIntercept GetClassToIntercept()
{
    //ClassToIntercept ReturnClass = new ClassToIntercept();
    ClassToIntercept ReturnClass = Intercept.ThroughProxy(new ClassToIntercept(), 
                                              new TransparentProxyInterceptor(), new[] { new InterceptionClass() });
    return ReturnClass;
}

Interception will work and what will happen will be determined from the InterceptionClass that will be explained in a minute.

If you wanted to avoid deriving from MarshalByRef you could have implemented an interface for your initial class such as:

public interface IClassToIntercept
{
    int GetRandomNumber(int min, int max);
}

Have your class implement this interface and your factory return the Interface instead of the class. This would mean that you program your whole software to the Interface and not to the actual class (which is not a bad programming practice either although it cannot be applied easily to any scenario). Nevertheless, if this is the case, then your factory would now be like the following:

public static IClassToIntercept GetClassToInterceptInterface()
{
    //IClassToIntercept ReturnClass = new ClassToIntercept();
    IClassToIntercept ReturnClass = Intercept.ThroughProxy<IClassToIntercept>(new ClassToIntercept(), new InterfaceInterceptor(),
                                             new[] { new InterceptionClass() });
    return ReturnClass;
}

For all those to work you need to have the Enterprise Library installed and add as References Microsoft.Practices.Unity and Microsoft.Practices.Unity.Interceptions. The Interception class is as follows (the Invoke method is the one doing the job!):

public class InterceptionClass:IInterceptionBehavior
{
    public IEnumerable<Type> GetRequiredInterfaces() {
        return Type.EmptyTypes;
    }
    
    public IMethodReturn Invoke(IMethodInvocation input,GetNextInterceptionBehaviorDelegate getNext){
        Console.WriteLine("Before the method");
        var methodReturn = getNext().Invoke(input, getNext);
        if (methodReturn.Exception == null)
            Console.WriteLine("After the method");
        else 
            Console.WriteLine("Ater the method with exception");
        return methodReturn;
    }
    
    public bool WillExecute {
        get { return true; }
    }
    
}

References

Aspect-Oriented Programming, Interception and Unity 2.0 (Dino Esposito)

Interceptors in Unity (Dino Esposito)

Using PostSharp(link)

PostSharp is a great tool and can achieve the most clean interception possible (meaning no changes in your classes and object generation at all even if you do not your factories for object creation and/or interfaces) but it is not a free library. Rather than creating proxies at runtime, it injects code at compile time and therefore changes your initial program in a seamless way to add method interception.

To achieve the same result you include PostsSharp.dll in your project and then create an attribute such as:

[Serializable]
public sealed class TraceAttribute : OnMethodBoundaryAspect
{
    public override void OnEntry(MethodExecutionArgs args)
    {
        Console.WriteLine("Before the method");
    }

    public override void OnExit(MethodExecutionArgs args)
    {
        Console.WriteLine("After the method");
    }
}

Now you can add the following attribute making all methods of ClassToIntercept Intereptable (you can also apply the Trace attribute to classes/methods if you can change the original code):

[assembly: Trace(AttributeTargetTypes = "Interceptions.ClassToIntercept")]

The cool thing in this is that you do not change anything else in your code, so your object can be still generated using the new keyword.

In this post, I have demonstrated two very easy approached in providing method interceptors n your programs. The complete demo project can be downloaded here

本文链接

WPF Snippet Tutorial - Aligning ListView Items

2010-08-27T02:01:00Z

WPF is powerful. So powerful in fact, that sometimes it's hard to find styles and settings to make it do what you want. Aligning ListView items was one such example for me. This snippet tutorial will show you how to use a style to vertically and horizontally align the contents of ListView cells.

I came across the need to vertically align the contents of my ListView when I had columns that contained elements that were different heights. By default, the ListView vertically aligns all of the content to the middle. I wanted them aligned to the top.

Here's a quick application I threw together to demonstrate what I'm talking about. It has a ListView bound to a collection of VideoGame objects. Each video game contains the title and an image of the box art. First, the object and some code to populate it:

public class VideoGame
{
public string Name
{
get;
set;
}
public string Image
{
get;
set;
}
}

...

public partial class Window1 : Window
{
private ObservableCollection<VideoGame> _games =
new ObservableCollection<VideoGame>();
public ObservableCollection<VideoGame> Games
{
get { return _games; }
}
public Window1()
{
    _games.Add(new VideoGame() {
      Name = "Crysis",
Image = @"C:\Crysis_Boxart_Final.jpg" });
    _games.Add(new VideoGame() {
      Name = "Unreal Tournament 3",
Image = @"C:\Gearsofwar.JPG" });
    _games.Add(new VideoGame() {
      Name = "Gears of War",
Image = @"C:\Crysis_Boxart_Final.jpg" });
    InitializeComponent();
}
}

And here's the XAML that displays this information:

When you launch this application, you'll get something that looks like this:

As you can see, each title is centered vertically to the image. I want to align it to the top. Here's the style needed to accomplish this:

<ListView.ItemContainerStyle>
<Style TargetType="ListViewItem">
<Setter Property="VerticalContentAlignment" Value="Top" />
</Style>
</ListView.ItemContainerStyle>

Now if we slap that into our ListView, we'll get exactly what we're looking for:

We can also use this style to horizontally align the content. Let's say I wanted to align all of the titles to the right as well as the top. All we'd have to do is change our style to this:

<ListView.ItemContainerStyle>
<Style TargetType="ListViewItem">
<Setter Property="VerticalContentAlignment" Value="Top" />
<Setter Property="HorizontalContentAlignment" Value="Right" />
</Style>
</ListView.ItemContainerStyle>

本文链接

WPF Tutorial - How To Use A DataTemplateSelector

2010-08-26T10:30:00Z

DataTemplates are an extremely powerful part of WPF, and by using them, you can abstract all sorts of display code. However, there are times when they fall short - and initially when I was learning WPF I was disappointed by that. For instance, you only get to set one DataTemplate on an items control, and while that made sense, it felt limiting. What if I wanted to use different templates depending on the content of the item? Do I have to build all that logic into a single data template?

And then I discovered DataTemplateSelectors! They are WPF's answer to the question I posed above - they let you write some logic that chooses what data template to use for an item. You could even, say, create an entirely new data template on the fly if you needed to. And it helps with one of WPF's main goals, separating out display (the DataTemplate itself) from logic (the DataTemplateSelector).

We are going to write a simple little application today, that is essentially just a list view containing a collection of strings. However, there is a twist - if the string is a path to an image on disk, instead of displaying the string, the list view will display the image. You can see a screenshot of it in action below:

Time to dive into some code. First, lets write the two DataTemplates we need - one displaying the image, and one for displaying the string:

Simple enough stuff. For when we just want to display the string, we use a TextBlock and bind the Text to the current item. When that string is an image path, however, we will be using an Image and binding the Source property to the string. The only quirk here is how the source property gets interpreted. If the path is relative, the Source property will think it is a reference to an internal program resource, and not a file on disk. So we have a converter that takes the relative path string and converts it to an absolute path string. You can learn more about binding converters here, in a tutorial that The Reddest wrote just the other day.

Since I was just talking about the converter, might as well get the code for it out of the way:

public class RelativeToAbsolutePathConverter : IValueConverter
{
public object Convert(object value, Type targetType,
object parameter, CultureInfo culture)
{
String relative = value as string;
if (relative == null)
return null;
return System.IO.Path.GetFullPath(relative);
}
public object ConvertBack(object value, Type targetType,
object parameter, CultureInfo culture)
{
throw new NotImplementedException();
}
}

All we do is cast the value to a string, and then use the handy GetFullPath method to get the full path for the given relative path. Since we don't need to use the ConvertBack method, I just have it set to throw a NotImplementedException.

Now that we have our Data Templates, lets write the DataTemplateSelector:

public class ImgStringTemplateSelector : DataTemplateSelector
{
public DataTemplate ImageTemplate { get; set; }
public DataTemplate StringTemplate { get; set; }
public override DataTemplate SelectTemplate(object item,
DependencyObject container)
{
String path = (string)item;
String ext = System.IO.Path.GetExtension(path);
if (System.IO.File.Exists(path) && ext == ".jpg")
return ImageTemplate;
return StringTemplate;
}
}

As you can see, to make your own DataTemplateSelector you create a class that extends the class DataTemplateSelector. This class has a single method that we need to override - SelectTemplate. This method will get called and get passed an item, and it needs to return what DataTemplate to use for that item. Here, we expect the item to be a string - and if the string represents a file path, and the file exists, and the extension is ".jpg", we return the template we are using for images, otherwise we return the template we are using for strings.

You are probably wondering, however, where the properties ImageTemplate and StringTemplate actually get set to the Data Templates we created earlier. Well, this happens in the xaml when we create an instance of the ImgStringTemplateSelector:

<local:ImgStringTemplateSelector
ImageTemplate="{StaticResource imageTemplate}"
StringTemplate="{StaticResource stringTemplate}"
x:Key="imgStringTemplateSelector" />

Ok, now it is time to throw all of the xaml out there so that you can see how the ListView actually uses the ImgStringTemplateSelector we just created:

The templates and the selector are all resources in the current window. This makes it so that when we get down to creating the ListView, we can set the ItemTemplateSelector to the static resource imgStringTemplateSelector. We also set the ItemsSource - we bind it to the PathCollection on the element This. What is the element This? Well, it happens to be the name of the window - you can see it up in the Nameproperty of the Window tag. And the PathCollection is a property on Window1:

public partial class Window1 : Window
{
ObservableCollection<string> _PathCollection = new ObservableCollection<string>();
public Window1()
{
    _PathCollection.Add("Sunset.jpg");
    _PathCollection.Add("I'm not an image");
    _PathCollection.Add("Blue hills.jpg");
    _PathCollection.Add("Water lilies.jpg");
    _PathCollection.Add("More string action");
    _PathCollection.Add("Winter.jpg");
    InitializeComponent();
}
public ObservableCollection<string> PathCollection
{ get { return _PathCollection; } }
}

The only other thing of note is the fact that ScrollViewer.CanContentScroll is set to false on the ListView. This is just there to enable smooth scrolling on the list box - it doesn't try and scroll the items one at a time, it lets you scroll partially through an item. It is just a nicety because the ListView will contain images.

Well, that is it for this introduction to the DataTemplateSelector. You can grab the Visual Studio project for what we wrote today here. And, as always, leave any questions or comments below.

本文链接

Dependency Properties

2010-08-26T09:03:00Z

Dependency Properties

Introduction

Value resolution strategy

The magic behind it

How to create a DepdencyProperty

Readonly DependencyProperties

Attached DependencyProperties

Listen to dependency property changes

How to clear a local value

Introduction

When you begin to develop appliations with WPF, you will soon stumble across DependencyProperties. They look quite similar to normal .NET properties, but the concept behind is much more complex and powerful.

The main difference is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the GetValue() method that is inherited from DependencyObject.

When you set a value of a dependency property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set.

The advantages of dependency properties are

Reduced memory footprint
It's a huge dissipation to store a field for each property when you think that over 90% of the properties of a UI control typically stay at its initial values. Dependency properties solve these problems by only store modified properties in the instance. The default values are stored once within the dependency property.
Value inheritance
When you access a dependency property the value is resolved by using a value resolution strategy. If no local value is set, the dependency property navigates up the logical tree until it finds a value. When you set the FontSize on the root element it applies to all textblocks below except you override the value.
Change notification
Dependency properties have a built-in change notification mechanism. By registering a callback in the property metadata you get notified, when the value of the property has been changed. This is also used by the databinding.

Value resolution strategy

Every time you access a dependency property, it internally resolves the value by following the precedence from high to low. It checks if a local value is available, if not if a custom style trigger is active,... and continues until it founds a value. At last the default value is always available.

The magic behind it

Each WPF control registers a set of DependencyProperties to the static DependencyProperty class. Each of them consists of a key - that must be unique per type - and a metadata that contain callbacks and a default value.

All types that want to use DependencyProperties must derive from DependencyObject. This baseclass defines a key, value dictionary that contains local values of dependency properties. The key of an entry is the key defined with the dependency property.
When you access a dependency property over its .NET property wrapper, it internally calls GetValue(DependencyProperty) to access the value. This method resolves the value by using a value resolution strategy that is explained in detail below. If a local value is available, it reads it directly from the dictionary. If no value is set if goes up the logical tree and searches for an inherited value. If no value is found it takes the default value defined in the property metadata. This sequence is a bit simplified, but it shows the main concept.

How to create a DependencyProperty

To create a DependencyProperty, add a static field of type DepdencyProperty to your type and call DependencyProperty.Register() to create an instance of a dependency property. The name of the DependendyProperty must always end with ...Property. This is a naming convention in WPF.

To make it accessable as a normal .NET property you need to add a property wrapper. This wrapper does nothing else than internally getting and setting the value by using the GetValue() and SetValue() Methods inherited from DependencyObject and passing the DependencyProperty as key.

Important: Do not add any logic to these properties, because they are only called when you set the property from code. If you set the property from XAML the SetValue() method is called directly.

If you are using Visual Studio, you can type propdp and hit 2x tab to create a dependency property.

// Dependency Property
public static readonly DependencyProperty CurrentTimeProperty = 
     DependencyProperty.Register( "CurrentTime", typeof(DateTime),
     typeof(MyClockControl), new FrameworkPropertyMetadata(DateTime.Now));   // .NET Property wrapper
public DateTime CurrentTime
{
    get { return (DateTime)GetValue(CurrentTimeProperty); }
    set { SetValue(CurrentTimeProperty, value); }
}

Each DependencyProperty provides callbacks for change notification, value coercion and validation. These callbacks are registered on the dependency property.

new FrameworkPropertyMetadata( DateTime.Now, 
                       OnCurrentTimePropertyChanged, 
                       OnCoerceCurrentTimeProperty ),
                       OnValidateCurrentTimeProperty );

Value Changed Callback

The change notification callback is a static method, that is called everytime when the value of the TimeProperty changes. The new value is passed in the EventArgs, the object on which the value changed is passed as the source.

private static void OnCurrentTimePropertyChanged(DependencyObject source, 
        DependencyPropertyChangedEventArgs e)
{
    MyClockControl control = source as MyClockControl;
    DateTime time = (DateTime)e.NewValue;
    // Put some update logic here...
}

Coerce Value Callback

The coerce callback allows you to adjust the value if its outside the boundaries without throwing an exception. A good example is a progress bar with a Value set below the Minimum or above the Maximum. In this case we can coerce the value within the allowed boundaries. In the following example we limit the time to be in the past.

private static object OnCoerceTimeProperty( DependencyObject sender, object data )
{
    if ((DateTime)data > DateTime.Now )
    {
        data = DateTime.Now;
    }
    return data;
}

Validation Callback

In the validate callback you check if the set value is valid. If you return false, an ArgumentException will be thrown. In our example demand, that the data is an instance of a DateTime.

private static bool OnValidateTimeProperty(object data)
{
    return data is DateTime;
}

Readonly DependencyProperties

Some dependency property of WPF controls are readonly. They are often used to report the state of a control, like the IsMouseOver property. Is does not make sense to provide a setter for this value.

Maybe you ask yourself, why not just use a normal .NET property? One important reason is that you cannot set triggers on normal .NET propeties.

Creating a read only property is similar to creating a regular DependencyProperty. Instead of calling DependencyProperty.Register() you call DependencyProperty.RegisterReadonly(). This returns you a DependencyPropertyKey. This key should be stored in a private or protected static readonly field of your class. The key gives you access to set the value from within your class and use it like a normal dependency property.

Second thing to do is registering a public dependency property that is assigned to DependencyPropertyKey.DependencyProperty. This property is the readonly property that can be accessed from external.

// Register the private key to set the value
private static readonly DependencyPropertyKey IsMouseOverPropertyKey = 
      DependencyProperty.RegisterReadOnly("IsMouseOver", 
      typeof(bool), typeof(MyClass), 
      new FrameworkPropertyMetadata(false));   // Register the public property to get the value
public static readonly DependencyProperty IsMouseoverProperty = 
      IsMouseOverPropertyKey.DependencyProperty;   // .NET Property wrapper
public int IsMouseOver
{
   get { return (bool)GetValue(IsMouseoverProperty); }
   private set { SetValue(IsMouseOverPropertyKey, value); }
}

Attached Properties

Attached properties are a special kind of DependencyProperties. They allow you to attach a value to an object that does not know anything about this value.

A good example for this concept are layout panels. Each layout panel needs different data to align its child elements. The Canvas needs Top and Left, The DockPanel needs Dock, etc. Since you can write your own layout panel, the list is infinite. So you see, it's not possible to have all those properties on all WPF controls.

The solution are attached properties. They are defined by the control that needs the data from another control in a specific context. For example an element that is aligned by a parent layout panel.

To set the value of an attached property, add an attribute in XAML with a prefix of the element that provides the attached property. To set the the Canvas.Top and Canvas.Left property of a button aligned within a Canvas panel, you write it like this:

<Canvas>
    <Button Canvas.Top="20" Canvas.Left="20" Content="Click me!"/>
</Canvas>

public static readonly DependencyProperty TopProperty =
    DependencyProperty.RegisterAttached("Top", 
    typeof(double), typeof(Canvas),
    new FrameworkPropertyMetadata(0d,
        FrameworkPropertyMetadataOptions.Inherits));   public static void SetTop(UIElement element, double value)
{
    element.SetValue(TopProperty, value);
}   public static double GetTop(UIElement element)
{
    return (double)element.GetValue(TopProperty);
}

Listen to dependency property changes

If you want to listen to changes of a dependency property, you can subclass the type that defines the property and override the property metadata and pass an PropertyChangedCallback. But an much easier way is to get the DependencyPropertyDescriptor and hookup a callback by calling AddValueChanged()

DependencyPropertyDescriptor textDescr = DependencyPropertyDescriptor.
    FromProperty(TextBox.TextProperty, typeof(TextBox));   if (textDescr!= null)
{
    textDescr.AddValueChanged(myTextBox, delegate
    {
        // Add your propery changed logic here...
    });
}

How to clear a local value

Because null is also a valid local value, there is the constant DependencyProperty.UnsetValue that describes an unset value.

button1.ClearValue( Button.ContentProperty );

本文链接

Introduction To Dependency Properties of WPF

2010-08-26T08:29:00Z

http://www.switchonthecode.com/tutorials/wpf-tutorial-introduction-to-dependency-properties

So I was going to dive right in and do a part 2 on the WPF ListView tutorial from last week, but as I was writing the code I realized that a lot of it relies on some new and very different constructs that WPF provides to developers. Two of these are deep enough topics on their own that I thought it would be a good idea to give an introduction to them before I dove back into the ListView stuff. So today we are going to talk about Dependency Properties, and in a future tutorial I will talk about how binding works in WPF.

What are dependency properties? The quick definition from the MSDN docs says that a dependency property is a "property that is backed by the WPF property system." Not really a great one-line explanation, but really, I can't blame them. I can't come up with a good one line explanation either. But essentially, it gives you a bunch of infrastructure to do all the things that you often want to do with a normal property - validate it, coerce it into a proper range, give out change notifications, and a number of other aspects. We aren't going to touch on everything that a dependency property can do today - because there is a lot. But we will be talking about how to use them, how to create them, and how to set up validation/coercion/change notification.

So one of the first things I thought was weird about the definition of a dependency property is that it is a static. This didn't make sense to me at first - this property needs to store info relevant to a particular instance of a class, how is it going to do that if it is static? But then, as I read more about them, I realized that a dependency property definition was exactly that - a definition. You are essentially saying that class A will have a property B - and it makes sense that that definition would be static. The actual storage of a value for a dependency property is deep inside the WPF property system - you never have to worry about it.

One thing you do have to note, though, is that for a class to contain dependency properties, it has to in some way derive from DependencyObject. In deriving from this class, you get all the infrastructure needed to participate in the WPF dependency property system.

So at first glance, all the properties on the new WPF controls seem to be regular old properties. But don't be fooled - this is often just a simple wrapper around a dependency property (and the documentation will usually say this). So what does it mean for a property to be a simple wrapper around a dependency property? Lets look at the FrameworkElement.Height property as an example:

public double Height

{ 

  get 

  { 

    return (double)GetValue(HeightProperty); 

  }

  set 

  { 

    SetValue(HeightProperty, value); 

  }

}

Your first two questions are probably "What are these GetValue and SetValue functions?" and "What is this HeightProperty?", and those are very good questions indeed. Well, GetValue and SetValue are functions you get by deriving from DependencyObject. They allow you, as you might have guessed, to get and set the values of dependency properties. The HeightProperty is the dependency property itself - the static definition part of the FrameworkElement class.

So far, this is just added complexity, and you're wondering why there is yet another level of indirection on things. But here is where things get interesting. In the "old ways", to set up some sort of change notification on the Height property here, you would have had to override it in a new class deriving from this FrameworkElement class and added whatever you needed in the 'set' part of the property here. However, you no longer have to do things like that. Instead, you can:

FrameworkElement myElement;

//

// myElement gets set to an element

//

DependencyPropertyDescriptor dpd;

dpd = DependencyPropertyDescriptor.FromProperty(

    FrameworkElement.HeightProperty, typeof(FrameworkElement))

dpd.AddValueChanged(myElement, myHeightChangedFunction);

And now you have a function that will get called any time the height changes on myElement! I think that is pretty handy. You can detach the hook just as easily:

DependencyPropertyDescriptor dpd;

dpd = DependencyPropertyDescriptor.FromProperty(

    FrameworkElement.HeightProperty, typeof(FrameworkElement))

dpd.RemoveValueChanged(myElement, myHeightChangedFunction);

Ok, enough about other people's dependency properties - lets go make our own! Below we have a extremely simple class with a dependency property for "LastName", as well as a property wrapper around it:

public class Person : DependencyObject

{

  public static readonly DependencyProperty LastNameProperty = 

      DependencyProperty.Register("LastName", typeof(string), typeof(Person));

  public string LastName

  {

    get

    {

      return (string)GetValue(LastNameProperty);

    }

    set

    {

      SetValue(LastNameProperty, value);

    }

  }

}

The Register call is pretty simple - you give the property a name (in this case "LastName"), you say what type of information the property will hold (in this case a string), and you say what type of object this property is attached to (in this case Person). A little verbose, especially when you add in the property wrapper, but not too bad. And I'm sure Microsoft will find a way to streamline the syntax in the next version of C#.

A little bit of a side note here - don't ever put anything but the GetValue and SetValue calls inside the property wrapper. This is because you never know if someone will set the property through the wrapper, or straight through a SetValue call - so you don't want to put any extra logic in the property wrapper. For example, when you set the value of a dependency property in XAML, it will not use the property wrapper - it will hit the SetValue call directly, bypassing anything that you happened to put in the property wrapper.

Back to creating dependency properties. The constructor for Register has a couple more optional arguments. And we are going to jump right in and use them all!

public class Person : DependencyObject

{

  public static readonly DependencyProperty LastNameProperty =

      DependencyProperty.Register("LastName", typeof(string), typeof(Person), 

      new PropertyMetadata("No Name", LastNameChangedCallback, LastNameCoerceCallback), 

      LastNameValidateCallback);

  private static void LastNameChangedCallback(

      DependencyObject obj, DependencyPropertyChangedEventArgs e) 

  {

    Console.WriteLine(e.OldValue + " " + e.NewValue);

  }

  private static object LastNameCoerceCallback(DependencyObject obj, object o) 

  {

    string s = o as string;

    if (s.Length > 8)

      s = s.Substring(0, 8);

    return s;

  }

  private static bool LastNameValidateCallback(object value)

  {

    return value != null;

  }

  public string LastName

  {

    get

    {

      return (string)GetValue(LastNameProperty);

    }

    set

    {

      SetValue(LastNameProperty, value);

    }

  }

}

The two other arguments to Register are a PropertyMetadata instance and a validateValueCallback. There are a couple different classes that derive from PropertyMetadata, but today we are just using the base one. The PropertyMetadata instance allows us to set a default value (in this case "No Name"), a property changed callback (LastNameChangedCallback), and a coerce value callback (LastNameCoerceCallback). The default value does exactly what you might expect. The change callback can do whatever you want it to do, and you have plenty of information with which to do it. The DependencyPropertyChangedEventArgs contain both the old and the new values of the property, as well as a reference to what property was changed. And the DependencyObject passed in is the object on which the property was changed. This is needed because, as you can see, this method is static. So every time the "LastName" property is changed on any object, this function will get called.

The same goes for the coerce callback - we get the object on which the property is being changed, and the possible new value. Here we get the opportunity to change the value - in this case, apparently last names are forced to be 8 characters or less.

And finally, we have the LastNameValidateCallback. This just gets the possible new value, and returns true or false. If it returns false, an exception is blown - so in this case, if anyone ever tries to set a null last name, they better watch out.

So there you go, the basics on dependency property usage and creation. There are a couple areas I haven't covered - inheritance, attached properties, and overriding metadata to name a few. But hopefully this gets off on the right foot with respect to dependency properties, and I'll probably write a tutorial in the next few weeks on those other areas. As always, questions and comments are welcome.

本文链接

朋友的公司招.net程序员2名及项目经理1名

2009-04-01T15:53:00Z

好久不来了，也不知道现在的规矩，发个帮朋友公司招人的广告不知道是不违规。违规的话请dudu删除吧！招收.net开发工程师2名项目经理1名：1、三年以上工作经验、两年以上.Net开发经验，精通C#、能指导程序员进行编码；2、具有B/S、C/S架构进销存项目开发经验；了解三层架构模式；3、精通SqlServer和mysql数据库原理及应用 4、有比较丰富的项目架构设计经验；5、对数据库设计熟悉、能...

Simple Object Access Protocol (SOAP) 1.1

2008-05-07T02:40:00Z

Simple Object Access Protocol (SOAP) 1.1 W3C Note 08 May 2000This version:http://www.w3.org/TR/2000/NOTE-SOAP-20000508Latest version:http://www.w3.org/TR/SOAPAuthors (alphabetically):Don Box, DevelopM...