.NET 框架中的 XML：在 .NET 框架中使用 XML 架构执行代码生成(2)

答案：     扩展 XSD 处理
  为了自定义处理过程，我需要将信息传递给该工具，以便它知道要更改或处理的内容。此时有两种主要选择：
  
  • 向 XSD 根 元素添加可被我的处理器理解的特性（可能添加很多），以便应用自定义，这种方法类似于类型化数据集方法。 单击此处可获得更多相关信息。
   
  • 通过架构注释使用内置的 XSD 可扩展性，以便任意进行自定义。它只需向某种代码生成管线中添加类型，即可在基本生成发生后执行。 
   
  
  第一种方法最初可能很有吸引力，因为它非常简单。我只需添加一个特性，然后相应地修改处理器以检查该特性：
  
  架构：
  
  <xs:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:code="http://weblogs.asp.net/cazzu" code:fieldsToProperties="true">
  
  代码：
  
  XmlSchema xsd;
  // Load the XmlSchema.
  ...
  foreach (XmlAttribute attr in xsd.UnhandledAttributes)
  {
    if (attr.NamespaceURI == "http://weblogs.asp.net/cazzu")
    {
      switch (attr.LocalName)
      {
        case "fieldsToProperties":
          if (bool.Parse(attr.value)) ConvertFieldsToProperties(ns);
          break;
        ...
      }
    }
  }
  
  这正是您通常会在其他从 xsd 到类的生成器中看到的方法（您可以在 Code Generation Network 中找到大量类似的生成器）。遗憾的是，该方法将导致长长的 switch 语句、无尽的特性，并最终导致代码难以维护并缺乏可扩展性。
  
  第二种方法更为健壮，因为它从一开始就考虑了可扩展性。XSD 通过 元素提供此类扩展工具，该元素可以是架构中几乎所有项目的子元素。我将利用该元素及其 子元素，以便使开发人员可以指定运行哪些（任意）扩展以及按什么顺序运行。这样的扩展架构将如下所示：
  
  <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:annotation> <xs:appinfo> <Code xmlns="http://weblogs.asp.net/cazzu"> <Extension Type="XsdGenerator.Extensions.FieldsToPropertiesExtension, XsdGenerator.CustomTool" /> </Code> </xs:appinfo> </xs:annotation>
  
  当然，每个扩展都将需要实现一个公共接口，以便自定义工具可以轻松地执行各个扩展：
  
  public interface ICodeExtension { void Process( System.CodeDom.CodeNamespace code, System.Xml.Schema.XmlSchema schema ); }
  
  通过预先提供此类可扩展性，当产生新的自定义需要时，就可以很容易地进行其他自定义。甚至还可以从一开始就将最基本的代码实现为扩展。
  
  可扩展的代码生成工具
  我将修改 Processor 类以添加这种新功能，并且将简单地从架构中检索各个 元素。尽管如此，这里还需要提出一个警告：与那些为元素、特性、类型等公开的 Post Schema Compilation Infoset 属性不同，在架构级别没有针对注释的类型化属性。也就是说，没有 XmlSchema.Annotations 属性。因此，需要对 XmlSchema.Items 的一般性预编译属性进行迭代，以便查找注释。而且，在检测到 XmlSchemaAnnotation 项目之后，再次需要对其自己的 Items 一般性集合进行迭代，这是因为除了 子元素以外，还可能有 子元素，而它也缺少类型化属性。当最终通过 XmlSchemaAppInfo.Markup 属性获得 appinfo 的内容之后，我们所得到的全部内容是一个 XmlNode 对象数组。您可以想像如何进行后续处理：对节点进行迭代，再对其子元素进行迭代，等等。这将产生非常丑陋的代码。
  
  值得庆幸的是，XSD 文件只是一个 XML 文件，因此可以使用 XPath 来对其进行查询。
  
  为了提高执行速度，我将在 Processor 类中保留 XPath 的静态编译表达式，它将在其静态构造函数中进行初始化：
  
  public sealed class Processor
  {
    public const string ExtensionNamespace = "http://weblogs.asp.net/cazzu";
    private static XPathExpression Extensions;
    static Processor() 
    {
      XPathNavigator nav = new XmlDocument().CreateNavigator();
      // Select all extension types.
      Extensions = nav.Compile
      ("/xs:schema/xs:annotation/xs:appinfo/kzu:Code/kzu:Extension/@Type");
      // Create and set namespace resolution context.
      XmlNamespaceManager nsmgr = new XmlNamespaceManager(nav.NameTable);
      nsmgr.AddNamespace("xs", XmlSchema.Namespace);
      nsmgr.AddNamespace("kzu", ExtensionNamespace);
      Extensions.SetContext(nsmgr);
    }
  
  注 有关 XPath 预编译和执行的优点、细节和高级应用的更多信息，请参阅 Performant XML (I): Dynamic XPath expressions compilation 和 Performant XML (II): XPath execution tips。
  
  Process() 方法需要在将 CodeNamespace 返回给调用方之前，执行该查询并执行它找到的每个 ICodeExtension 类型：
  
  XPathNavigator nav;
  using ( FileStream fs = new FileStream( xsdFile, FileMode.Open ) )
  { nav = new XPathDocument( fs ).CreateNavigator(); }
  XPathNodeIterator it = nav.Select( Extensions );
  while ( it.MoveNext() )
  {
    Type t = Type.GetType( it.Current.value, true );
    // Is the type an ICodeExtension?
    Type iface = t.GetInterface( typeof( ICodeExtension ).Name );
    if (iface == null)
      throw new ArgumentException( "Invalid extension type '" + 
         it.Current.value + "'." );
    ICodeExtension ext = ( ICodeExtension ) Activator.CreateInstance( t );
    // Run it!
    ext.Process( ns, xsd );
  }
  return ns;
  
  我使用 Type.GetInterface() 而不是 Type.IsAssignableFrom() 来测试接口实现情况，因为它能够快速跳到非托管代码，所以需要的开销较少。它们的效果是相同的，然而，使用后者将返回一个布尔值，而不是一个“类型”（如果未找到接口，则返回空值）。
  
  返回页首
  XmlSerializer 的内部原理
  有了 CodeDom 以后，可以为追求自定义的开发人员带来大量能力和灵活性，但同时也带来了更大的责任。以这种方式修改代码会有危险，因为这会使代码不再按与架构兼容的方式进行序列化，或者 XmlSerializer 功能被完全破坏，并针对意外的节点和特性引发异常，从而无法检索值，等等。
  
  因此，在处理生成的代码之前，绝对需要了解 XmlSerializer 的内部原理，当然也就需要一种了解其内部原理的方法。
  
  当对象即将进行 XML 序列化时，将通过反射您传递给 XmlSerializer 构造函数的类型来创建一个临时程序集（这就是您需要那么做的原因）。请等一下！不要因为“反射”一词而感到害怕！这对于每个类型只执行一次，并且在 AppDomain 生命期内，将创建一对极为有效的 Reader 和 Writer 类来处理序列化和反序列化。
  
  这些类继承了 System.Xml.Serialization 命名空间中的 XmlSerializationReader 和 XmlSerializationWriter 公共类。它们还是 [TheTopSecretClassName]。如果您希望看一下这些动态生成的类，您只需向应用程序配置文件（对于 Web 应用程序，为 web.config）中添加以下设置：
  
  <system.diagnostics> <switches> <add name="XmlSerialization.Compilation" value="4"/> </switches> </system.diagnostics>
  
  现在，序列化程序将不会删除在该过程中生成的临时文件。对于 Web 应用程序，这些文件将位于 C:\Documents and Settings\[YourMachineName]\ASPNET\Local Settings\Temp 中；或者，它们将位于当前用户的 Local Settings\Temp 文件夹中。
  
  您将看到的代码就是当您希望有效地加载 .NET 中的 XML 时需要编写的代码：使用嵌套的 while 和 if 语句进行读取，使用 XmlReader 方法在数据流中向下移动，等等。使用这些丑陋代码的目的就是使该处理过程真正地快起来。
  
  还可以通过使用 Chris Sells 的 XmlSerializerPreCompiler 工具来诊断所

上一个：.NET 框架中的 XML：在 .NET 框架中使用 XML 架构执行代码生成(3)
下一个：.NET 框架中的 XML：在 .NET 框架中使用 XML 架构执行代码生成(1)