UML软件工程组织

Visual Studio 2005窗体配置文件
来源:天极网 作者: 陶刚
  .NET的最新版本把强数据类型扩展到了配置文件中,添加了设置的范围、基于GUI的属性编辑器和拖放配置类的只读约束。

  在即将发布的.NET 2.0的一些新特性中,包含了对System.Configuration名称空间的修补和Visual Studio 2005配置编辑器。与以前的实现方式相比,新的类把桌面和Web应用程序的配置方法提升到了一个完善的新的层次。本文聚焦于简单的桌面应用程序,该应用程序的唯一目的是显示和修改自己的配置文件的内容。如果要运行这个应用程序,你必须下载Visual Studio 2005公众beta版。

  一些新特性

  最重要的两个配置文件特性是用于类型安全性的强数据输入和用户设置信息范围的分离和编辑。

  ·类型安全性(Type Safety)

  以前的.NET框架组件只允许字符串设置信息。当我们把设置信息直接读入非字符串变量的时候,就会遇到一些问题,如下所示:
int maxConnections =
ApplicationSettings.AppSettings.Key["MaxConnections"];

  如果配置信息的内容不是字符串,而表现为其它的数据类型,例如布尔型、整型或更复杂的数据类型,你就必须编写定制的代码,转换字符串值或建立并填充适当的对象。与此形成对照的是,新的API为实现定制的串行化程序处理了所有基本数据类型和接口。此外框架组件还为一些经常用到的编程结构(例如数据源连接和URL)提供了内建的处理程序。

  ·范围(Scopes)

  新API使用了一个叫做范围(scopes)的概念来区分应用程序与用户设置。你需要使用Application(应用程序)范围来设置应用程序的一些细节信息(例如连接字符串)和其它驱动应用程序的一些值,这些值一般不会(不倾向于)改变。User(用户)范围是用于存放用户可配置的应用程序值的(例如最后的窗口位置和最常使用的文档)。更重要的是,User范围为每项设置存储了默认值。当用户使用应用程序改变这些默认值的时候,配置文件把这些更新后的值存储在单独的位置中。这是很重要的,因为它保证了应用程序配置文件的完整性,并且把用户特定的数据保存在用户的系统配置中。不用进行任何额外的开发,配置框架组件就能在后台自动地把用户特定的设置信息读取出来。

  ·ThisConfigEditor应用程序

  本文中提供的示例应用程序ThisConfigEditor(图1所示),是一个用于显示自己的配置文件中的设置信息的简单工具。尽管非常简单,但是它可以作为满足大多数应用程序需求的很好的跳板。


图1:示例配置编辑器:显示示例项目配置文件的设置信息

  在这个项目中Visual Studio自动生成了大多数文件(图2所示)。


图2:Visual Studio为项目生成的文件,添加了ThisConfigEditor.cs文件

  唯一需要在代码编辑器中修改的文件是ThisConfigEditor.cs。这个应用程序不需要任何特殊的部件或资源,并且所有的配置设置信息都由Visual Studio新的属性编辑器来处理。当Visual Studio建立一个新项目的时候,它会自动地生成一个Properties文件夹,并且用处理属性编辑器生成的配置设置信息的类来填充它。属性编辑器自动地更新app.config文件和Settings.cs类文件(生成的属性的类包装),因此你不需要手动地处理这些文件;实际上,最好在你对新的配置文件标记的基础有透彻的理解之后,才手动处理这些文件。你可以在微软MSDN站点上找到配置文件标记的完整解释。

  ·属性编辑器

  请双击解决方案管理器中的"Settings.settings"条目载入属性编辑器。


图3:属性编辑器:双击"Settings.settings"条目载入属性编辑器

  图3显示的是为演示目的建立的两个配置属性:FilesDirectory和Connection。属性编辑器表格允许你指定名称、数据类型、范围(默认情况下有两种类型的范围:User和Application)和值。此处最有趣的属性是Connection设置。从类型(Type)下拉列表中选择(Connection string)会载入一系列的对话框,用于建立连接字符串(图4和图5所示)。


图4:选择数据源:从类型列表中选择连接字符串设置类型的时候,Visual Studio将载入一系列的对话框来定义字符串属性



图5:连接属性对话框:在选择连接字符串类型之后出现这个标准的连接属性对话框

  生成了什么样的内容?

  属性编辑器中的所有这些工作就是自动地生成配置设置信息和大量的代码。尽管深入了解这些内容超出了本文的范围,但是粗略地看一下是有好处的。如果你打开本文代码下载中的app.config文件,你可以看到在建立项目的时候Visual Studio建立了含有什么内容的ThisConfigEditor.exe.config文件。尽管我们更有兴趣的是Settings.Designer.cs源文件(也包含在下载的代码中)。这个类提供了按照从属于应用程序主名称空间(在例子中是Example.Properties,位于Settings类中)的名称空间中的名字对设置信息进行简单地和直接的访问。请注意特性(property)与每个配置设置信息相对应。包装每个特性的属性(attribute)定义了特性所处的范围和默认值。由于Settings类继承自ApplicationSettingsBase类(System.Configuration API中的一个新的集合类),你可以使用名称直接访问这些属性或者枚举所有的配置设置信息,ThisConfigEditor示例就是这样做的。

 枚举配置属性

  ThisConfigEditor的显示的核心是ThisConfigEditor.cs代码文件中的私有的PopulateListView方法:

private void PopulateListView()
{
 ListViewItem item = null;

 this.buttonUpdateSetting.Enabled = false;
 this.textBoxSettingValue.Enabled = false;
 this.listViewSettings.Items.Clear();

 Properties.Settings settings = Properties.Settings.Default;

 foreach (SettingsProperty property in settings.Properties)
 {
  bool match = false;

  switch (_dt)
  {
   case DisplayType.All:
    match = true;
    break;

   case DisplayType.Application:
    foreach (System.Collections.DictionaryEntry attribute in property.Attributes)
    {
     if (attribute.Value is System.Configuration.ApplicationScopedSettingAttribute)
     {
      match = true;
      break;
     }
    }
    break;

   case DisplayType.User:
    foreach (System.Collections.DictionaryEntry attribute in property.Attributes)
    {
     if (attribute.Value is System.Configuration.UserScopedSettingAttribute)
     {
      match = true;
      break;
     }
    }
    break;
   }

   if (match)
   {
    item = new ListViewItem(property.Name);
    item.SubItems.Add(new ListViewItem.ListViewSubItem(item, property.PropertyType.ToString()));
    item.SubItems.Add(new ListViewItem.ListViewSubItem(item, settings[item.Text] as string));
    item.Tag = property;
    this.listViewSettings.Items.Add(item);
   }
  }
 }

  通过判断私有枚举字段_dt(它与窗体中的组合框的选择相关联,该组合框用于选择显示哪些配置属性:全部的、应用程序的或者用户的),代码枚举出配置属性。集合中的每个成员都是一个SettingProperty实例(System.Configuration API中的另外一个新类,用于表现独立的配置属性),它也包含一个DictionaryEntry实例集合,用于表示它们的多个属性。通过在属性集合上进行迭代操作,代码搜索出与组合框中选择的范围相匹配的属性。在匹配到之后,代码显示通过建立一个新的ListViewItem并把它添加到窗体的ListView上,从而显示配置属性。

  我们的修改到哪儿去了?

  因此,在浏览了这些代码并运行该应用程序之后你可以看到ThisConfigEditor.exe.config文件中的不同配置设置信息。为了理解配置框架组件是如何工作的,我们来看一下当你改变一个User范围设置(图6所示)的时候发生了什么事情。


图6:改变User范围的设置信息

  改变的设置信息没有保存到应用程序的配置文件中;作为代替,该API在用户的配置(profile)中为应用程序建立了一个新目录(如果这个目录并不存在才建立),在这个目录中增加了一个叫做user.config的文件(图7所示)。


图7:新的用户配置文件:.NET框架组件保存的示例应用程序的新的用户配置文件的位置

  采用这种方法分离数据,通过使用户特定的数据与用户保持关联,保护了应用程序配置文件的完整性。而且,.NET框架组件自动地载入用户特定的内容而不需要开发者来干涉。请注意,最后的一个目录与应用程序的版本号相对应。这确保了当某个属性的数据类型发生改变的时候,应用程序的延续版本将维护它们独立的完整性而不会相互干扰。

  精简框架组件又落后了

  Pocket PC上的精简框架组件的实现有时候看起来不受.NET世界的重视。它的1.0版本的实现没有为System.Configuration名称空间和注册表做任何准备。2.0的beta版文档在System.Configuration名称空间中出现了每个类实体的精简框架组件,就像beta文档中的所有名称空间中的大量类的实现方法一样,但是现在是不支持的。

  人们只能希望这只是新的.NET平台的一个短暂的阶段,并且最后的发布版支持与桌面版相同的能力。

 

版权所有:UML软件工程组织