微软企业库代码的分析工作

1.介绍和使用
摘要
patterns & practices 企业程序库是一个设计为协助开发人员处理企业开发常见问题的应用程序块的程序库。应用程序块是指导类型的，它提供可由开发人员“按原样”使用、进行扩展或 修改的源代码，以用于企业开发项目。企业程序库包含以前作为独立应用程序块使用的应用程序块的新版本和更新版本。所有企业程序库应用程序块的更新都特别注重一致性、可扩展性、易于使用和集成。
企业程序库应用程序块
应用程序块可以帮助开发人员解决每个项目都会遇到的常见问题。它们在设计时封装了 Microsoft 推荐的 .NET 应用程序最佳做法。它们可以快速而轻松地插入到 .NET 应用程序中。例如，数据访问应用程序块提供对 ADO.NET 最常用功能的访问，并通过易于使用的类将其公开。应用程序块还添加了基础类库不直接支持的相关功能。
组成企业程序库的应用程序块如下：
•
缓存应用程序块。此应用程序块允许开发人员在其应用程序中集成本地缓存。
•
配置应用程序块。此应用程序块允许应用程序读/写配置信息。
•
数据访问应用程序块。此应用程序块允许开发人员在其应用程序中集成标准的数据库功能。
•
加密应用程序块。此应用程序块允许开发人员在其应用程序中包含加密和哈希功能。
•
异常处理应用程序块。此应用程序块允许开发人员和决策人员针对发生在企业应用程序体系结构层的异常处理创建一致的策略。
•
日志和规范应用程序块。此应用程序块允许开发人员在其应用程序中集成标准的日志和规范功能。
•
安全应用程序块。此应用程序块允许开发人员在其应用程序中集成安全功能。应用程序可在多种情况下使用应用程序块，例如，根据数据库验证和授权用户、检索角色和配置文件信息，以及缓存用户配置文件信息等。
不同的应用程序有不同的要求，您会发现并不是每个应用程序块在您构建的每个应用程序中都有用。在使用应用程序块之前，您应该对应用程序需求以及应用程序块计划处理的方案有充分的了解。
返回页首
我们的目标是建立一个广泛的客户和合作伙伴社区 — 使用、共享和扩展他们自己的与 patterns & practices 企业程序库相一致并集成到其中的应用程序块。例如，企业程序库的一部分是根据 Avanade Inc 授权的 ACA.NET 改写的。要参加该社区，请访问企业程序库社区站点。
企业程序库的主要主题如下：
•
一致性。所有应用程序块都注重设计模式、实现方法、配置机制、文档、示例、部署和操作处理的一致性。
•
可扩展性。开发人员可通过在可扩展点“插入”自已的代码或修改应用程序块的源代码，来自定义应用程序块的行为。企业程序库还包含帮助开发人员构建他们自己的与企业程序库相集成的应用程序块的指导。
•
易于使用。企业程序库包括许多对早期版本的应用程序块的可用性改进，其中包括一个配置工具 — 企业程序库配置控制台，这使得用这些块进行评估、安装、学习、配置和开发更加轻松。
•
集成。这些应用程序块被设计和测试为可以很好地一起（或独立）工作。
返回页首
什么是指导？
企业程序库是一个设计为可以重用、自定义和扩展的指导性产品。它不是 Microsoft 产品。下表描述了基于代码的指导性产品（包括企业程序库）的一些关键属性。
属性
描述
支持
基于代码的指导“按原样”提供，但不对此进行任何担保。客户可以获得支持，但 Microsoft 支持人员会认为该代码是用户编写的。patterns & practices 小组提供产品支持，并根据需要增加对他们的协助。我们鼓励客户通过在线社区互相支持。
功能性
为常见的企业开发难题提供灵活且体系结构合理的解决方案，如果从基础平台做起，没有一定的努力或广泛的相关知识是很难做到的。该指导通过使用基础平台功能并坚持其最佳做法来解决这些问题。该指导被设计为可由用户扩展和自定义。
发布
指导版本的开发通常有 3-6 个月的生命周期。当指导在现有的可用平台上就绪时就会发布。现有指导的新版本（可以进行修订以便在新版本的平台上运行）将在有足够多的用户需求时发布。
兼容性
基 于代码的指导被设计为帮助解决特定版本的 Microsoft 产品的问题。随着产品的更改，发布的指导也将更改或废弃。如果可能，我们将事先开发指导的未来版本。不保证指导与早期版本的指导或过去和未来的平台版本相 兼容。patterns & practices 小组推荐阶段迁移策略，同时为多种版本指导的共存提供较高的优先级。
形式要素
作为源代码发布。可变性是通过配置、所定义的可扩展点以及对源代码的直接修改实现的。文档重点介绍如何使用本指导、如何对其进行扩展，及其设计目标、模式和代价。
返回页首
2.功能的分析
缓存应用程序块简介
Enterprise Library Caching Application Block 1.0 版可让开发人员将本地缓存集成到其应用程序中。它支持内存缓存和后备存储（可选），后者可以是企业程序库数据访问应用程序块或独立存储。应用程序块无需修改即可使用，它还可以提供检索、添加和删除缓存数据所需的全部功能。可配置的过期时间与清除策略也是应用程序块的一部分功能。
在构建企业级分布式应用程序时，架构师和开发人员面临着许多难题。缓存可以帮助您克服其中的一些难题，包括：
•
性能。通过存储与数据使用者尽可能接近的相关数据，缓存可以提高应用程序的性能。这样可以避免重复进行数据创建、处理和传输。
•
可伸缩性。在缓存中存储信息有助于节省资源，并且可以随着应用程序需求的增加来提高可伸缩性。
•
可用性。通过将数据存储在本地缓存中，应用程序可以承受系统的故障，例如网络等待时间、Web 服务问题以及硬件故障。
常见情况
缓存应用程序块适用于以下任何一种情况：
•
必须重复访问静态数据或极少更改的数据。
•
在创建、访问或传输方面，数据访问的开销很高。
•
即使在源（例如服务器）不可用时，数据也必须始终可用。
缓存应用程序块可用于以下任何一个应用程序类型：
•
Windows 窗体
•
控制台
•
Windows 服务
•
企业服务
•
ASP.NET Web 应用程序或 Web 服务（如果您需要 ASP.NET 缓存中未包含的功能）
应该将缓存应用程序块部署在单个应用程序域中。每个应用程序域都可以有一个或多个缓存（可以有也可以没有后备存储）。缓存不能在不同的应用程序域之间共享。
缓存应用程序块的性能已优化，并且是线程安全和异常安全的。您可以对它进行扩展，以包括您自己的过期策略和后备存储。
缓存应用程序块的设计
缓存应用程序块旨在实现以下目标：
•
提供一组大小可以管理的 API
•
允许开发人员将标准的缓存操作集成到其应用程序中，而无需了解应用程序块的内部工作方式
•
可以使用企业程序库配置控制台轻松地进行配置
•
可以高效执行
•
线程安全
•
如果在访问后备存储时发生异常，可以确保后备存储不会受到影响
•
确保内存缓存的状态与后备存储的状态保持同步
设计要点
图 1 展示了缓存应用程序块中关键类的相互关系。

图 1.缓存应用程序块的设计
当使用 CacheFactory 初始化 CacheManager 的实例时，它会在内部创建一个 CacheManagerFactory 对象，而该对象又会创建一个Cache 对象。创建 Cache 对象后，后备存储中的所有数据就会加载到一个内存表示中，该表示包含在Cache 对象中。然后，应用程序可以请求 CacheManager 对象检索缓存数据、将数据添加到缓存中，以及从缓存中删除数据。
当应用程序使用 GetData 方法向 CacheManager 对象发送检索某项的请求时，CacheManager 对象就会将该请求转发给 Cache 对象。如果该项在缓存中，它就会从缓存的内存表示中返回到应用程序。如果它不在缓存中，该请求会返回NULL。如果该项位于缓存中但已过期，它也会返回 NULL。
当应用程序使用 Add 方法向 CacheManager 对象发送向缓存添加某项的请求时，CacheManager 对象同样会将该请求转发给 Cache 对象。如果已经有一个具有相同关键字的项，则在将新项添加到内存存储和后备存储中之前，Cache 对象会首先删除它。如果后备存储是默认的后备存储 NullBackingStore，则数据只写到内存中。在添加项时，如果缓存项的数量超过预定的限制，那么 BackgroundScheduler 对象就开始进行清理。在添加项时，应用程序可以使用Add 方法的重载来指定过期策略数组、清除的优先级，以及实现ICacheItemRefreshAction 接口的对象。还可以使用该对象来刷新缓存中的过期项。
BackgroundScheduler 对象周期性地监视缓存中各项的生存期。当某个项过期时，BackgroundScheduler 对象会首先删除它，然后再通知应用程序该项已被删除（可选）。此时，由应用程序负责刷新缓存。
配置应用程序块简介
几乎每个应用程序都需要某种格式的配置信息。这些信息可以像数据库连接字符串一样简单，也可以像多部分、分层的用户首选信息一样复杂。作为一名开发人员，如何存储应用程序的配置数据以及将它们存储在何处是您经常面临的问题。典型的解决方案包含以下内容：
•
使用配置文件（例如 XML 文件或 Windows .ini 文件）
•
使用 Windows 注册表
•
使用诸如 Microsoft SQL Server 这样的数据库
其 中每个选择都有其各自的优点和缺点；没有一种解决方案可以适合所有情况。在一个应用程序中，您可能需要采用多种方法来协调应用程序所需的不同类型的配置数 据。例如，如果您的应用程序运行在不同的环境中，您可能需要支持多种配置存储解决方案。要考虑的其他重要因素包括：确保应用程序配置数据的安全性和完整性，以及将存储解决方案对应用程序性能的影响降到最低程度。
Enterprise Library Configuration Application Block 1.0 版解决了这些问题，并提供了一种可以在所有应用程序中管理配置数据的解决方案。具体地说，配置应用程序块提供了一种灵活的数据模型、一种检索配置数据的简单方法和可扩展性。
配置应用程序块将读/写配置数据的能力与基础数据存储的细节相分离。通过利用存储提供程序和转换器在应用程序和物理存储之间传输数据，可以实现这一点。存储提供程序是可以读/写特定物理存储（例如XML 文件或 SQL 数据库）的对象。转换器可以在应用程序的期望格式（例如一组对象）和存储提供程序的要求格式（例如 XML 文档）之间转换配置信息。应用程序块随附有 XML 文件存储提供程序和 XML 序列化程序转换器。
您可以在包含有配置元数据的文件中定义存储提供程序和转换器。通常，该文件是 Machine.config 文件、App.config 文件或 Web.config 文件。元数据包含一些信息，例如，配置节名称、存储位置以及读/写配置设置时所使用的对象的类型名称。这意味着，您可以通过更改文件中的信息将一种存储类 型更改为另一种，而无需重新编写应用程序。
同样，您可以通过更改同一个文件来更改存储属性，例如其位置。这也不需要修改应用程序代码。在部署和操作期间可以决定在何处存储配置数据。
常见情况
配置应用程序块提供了一个用于读/写应用程序配置数据的简单接口。检索配置数据只需要一行代码。以下示例可从配置文件中检索一个数据库连接字符串。
[C#]string conString = (string)ConfigurationManager.GetConfiguration("connectionstring"); [Visual Basic]Dim conString As String = ConfigurationManager.GetConfiguration("connectionstring")
通过创建允许您使用其他数据存储（例如 Windows 注册表或 SQL数据库）的自定义存储提供程序，可以扩展配置应用程序块。通过更改配置元数据文件，可以将这些自定义提供程序添加到配置应用程序块中。您无需修改或重新构建配置应用程序块，即可使用不同的存储。您还可以添加自定义转换器来为应用程序和存储转换配置数据。
1.0 版本的主要特点
Enterprise Library Configuration Application Block 1.0 版使用企业程序库配置控制台来管理配置设置。它还允许您添加自己的存储提供程序和转换器。
从配置管理应用程序块迁移
Enterprise Library Configuration Application Block 1.0 版与配置管理应用程序块之间有明显的区别：
•
该版本的应用程序块支持在 XML 文件中存储配置数据。如果您已经使用了其他类型的数据存储（例如 Windows 注册表或 SQL 数据库），那么您可以创建自定义的存储提供程序和转换器，也可以将数据转换为 XML。
•
不再支持用名称/值对来表示配置数据，也不再支持哈希表序列化。要将配置数据读入应用程序或者将其写到配置文件中，您需要声明一个包含这些数据的类。该类应该能够使用转换器的输出。
配置应用程序块的依赖项
配置应用程序块依赖于企业程序库中包含的代码，包括通用程序库功能（例如，规范），它提供了各种功能来公开用于系统管理的事件和数据。
此外，应用程序块还使用 XML 文件来存储配置信息。修改这些信息的推荐方法是使用企业程序库配置控制台。
返回页首
配置应用程序块的设计
配置应用程序块旨在实现以下目标：
•
提供一个用于读/写配置数据的简单接口
•
将应用程序和配置数据的物理存储位置相分离
•
提供一种允许自定义存储位置和配置设置的运行时表示的可扩展模型
设计要点
图 1 展示组成配置应用程序块的类和对象之间的关系。该图假定您使用XML 文件存储提供程序和转换器，它们包含在应用程序块中。XML 文件存储提供程序以文件的形式存储配置数据。（其他提供程序使用其他形式的存储，例如 Windows 注册表。）XmlFileStorageProvider 对象指向一个包含特定配置节的配置设置的文件。ConfigurationBuilder 对象指向一个包含特定配置节的配置元数据的文件。通常，包含配置元数据的文件名为App.config（对于基于 Windows 的应用程序）或Web.config（对于基于 Web 的应用程序）。

图 1. 配置应用程序块的设计
配 置应用程序块将配置元数据和实际的配置设置分隔开来。应用程序块将元数据放在它自己的文件中，而该文件独立于存储配置设置的位置。配置设置经过分组并称为 配置节。应用程序使用的每个企业程序库应用程序块都有其自己的配置节，该配置节存储在其自己的文件中。配置应用程序块使用配置元数据来访问配置中的数据。
元数据指向配置存储位置并包含一些信息，例如，配置应用程序块读/写配置数据所需的转换器和存储提供程序的类型。配置元数据文件被分成节。每一节都包含在配置存储位置读/写一组特定的配置设置所需的信息。
ConfigurationManager 类提供一个在所定义的存储位置读/写特定配置节的配置设置的静态外观。ConfigurationManager 对象从应用程序域配置文件读取配置元数据，然后使用这些信息来读/写配置节信息。
ConfigurationManager 类的静态方法使用ConfigurationBuilder 对象的实例。ConfigurationBuilder 可创建文件存储提供程序和转换器对象。这些对象可管理配置数据和元数据。
IStorageProviderReader 接口定义了用于从存储位置读取配置信息的接口。IStorageProviderWriter 接口实现了 IStorageProviderReader 接口，还定义了用于写入配置信息的接口。配置应用程序块包含一个支持该接口的提供程序XmlFileStorageProvider，它在一个 XML文件中读/写配置数据。
ITransformer 接口可转换应用程序和存储提供程序之间的配置设置对象。配置应用程序块包含一个实现该接口的提供程序，即XmlSerializerTransformer 类。XmlSerializerTransformer 类实现了应用程序定义的运行时对象和XmlNode 对象之间的转换，而无需应用程序来配置转换器。如果没有转换器，配置设置对象就会以存储提供程序提供的相同格式返回到应用程序。
每个配置节的设置都缓存在一个哈希表中。当客户端请求配置数据时，ConfigurationBuilder 对象会在缓存中查找数据。如果在缓存中找到配置数据，ConfigurationBuilder 对象就不必访问存储中的配置数据。如果文件存储提供程序检测到存储中的配置数据已经更改，则 ConfigurationBuilder 对象就会清除缓存。ConfigurationManager 对象允许应用程序清除全部缓存，或者只清除给定节名的缓存。如果清除了缓存，则下一个读取操作就会访问存储位置中的配置设置。
总之，设计了配置应用程序块，您就可以用最适合应用程序要求的方式将配置数据存储在应用程序中。您不受存储方法的限制。IStorageProviderReader 与 IStorageProviderWriter 接口以及 ITransformer 接口（可选）将内存表示和物理存储中使用的表示分离开来。
数据访问应用程序块简介
Enterprise Library Data Access Application Block 1.0 版可以简化实现通用数据访问功能的开发任务。应用程序可以在很多情况下使用应用程序块，例如读取显示数据、获得通过应用程序层的数据，以及将更改过的数据提交回数据库系统等。应用程序块包括对存储过程和内嵌 SQL 以及常见内务处理任务（例如，管理连接、创建与缓存封装在应用程序块的方法中的参数）的支持。换句话说，数据访问应用程序块提供对最常用的 ADO.NET 功能的访问。
该应用程序块还简化了可移植应用程序代码的开发，允许多个数据库服务器（包括 Microsoft SQL Server、Oracle 和 DB2£©中的代码保持一致。为此，可以使用抽象基类来定义公共接口并提供数据访问方法的多种实现，为一种数据库（例如 SQL Server£©编写的应用程序看起来与为另一种数据库（例如 Oracle）编写的应用程序相同。通过使用数据访问应用程序块并遵循本文档中的准则，您的代码大部分都可以移植。
另一个功能是，应用程序代码可以通过名称（例如，“Customer”或“Inventory”）来引用特定的数据库。更改应用程序配置中的名称允许开发人员以不同的数据库配置来使用他们的应用程序，而无需重新编译他们的代码。
数据访问应用程序块具有以下功能：
•
它可以减少编写样本代码以执行标准任务的需要。
•
它有助于在应用程序和整个企业中维护一致的数据访问做法。
•
它可以降低更改物理数据库目标的难度。
•
它使开发人员免于学习不同类型数据库的不同编程模型。
•
将应用程序移植到不同类型的数据库时，它可以减少需要重新编写的代码数量。
常见情况
开 发人员经常要编写使用数据库的应用程序。因为很常见，所以开发人员可能会发现自己为每个应用程序反复编写了相同的代码。另外，这些应用程序可能需要与不同 类型的数据库一起工作。虽然任务相同，但必须要改写代码以符合每个数据库编程模型的要求。数据访问应用程序块通过提供最常见数据访问任务的实现，从而解决了这些问题。开发人员只需完成以下工作：
1.
创建数据库对象。
2.
提供命令的参数（如果需要）。
3.
调用适当的方法。
这些方法都进行了性能优化。它们也可以移植。数据访问应用程序块可以透明地与 SQL Server、DB2 和 Oracle 数据库一同工作。
1.0 版本的主要特点
Enterprise Library Data Access Application Block 1.0 版包含以下新功能：
•
用于管理配置设置的图形工具
•
支持多个数据库系统，并且能够添加其他系统
•
分别抽象数据库和连接字符串的工厂和命名实例
•
对参数缓存的支持已扩展为允许应用程序清除缓存
从先前版本的数据访问应用程序块迁移
早期版本的数据访问应用程序块用户应该了解企业程序库版本针对的多种情况。虽然当前版本是基于从早期版本获得的知识和反馈而构建的，但它在如何解决那些情况方面有了重大改变。
以下列表描述了企业程序库版本的数据访问应用程序块与早期版本的区别：
•
早期版本应用程序块中的静态 helper 方法已经由实例化数据访问对象的方法所取代。
•
现在还提供了接受新数据访问对象的另一种样式的重载。在使用该样式时，会通过两种重载公开所有的数据访问功能，一种是在事务外执行命令时使用，另一种是在事务内执行命令时使用。
•
每个数据访问方法的许多重载都已简化。
•
特定于数据库的对象由工厂创建，它使用配置信息来确定要创建对象的类型。
•
连接字符串信息已经移到配置文件，在调用方法时不再使用。使用企业程序库配置控制台可允许您配置数据库，如果需要，还可加密存储中的配置信息。
•
现在用一个单独的类来表示命令信息。开发人员创建并初始化命令对象，然后将其传递到 Database 类的适当方法中。
以下代码演示了某个应用程序使用数据访问应用程序块来执行一条返回数据集的数据库查询。
[C#]myDataSet = DatabaseFactory.CreateDatabase("Sales").ExecuteDataSet("GetOrdersByCustomer", myCustomerId ); [VB]myDataSet = DatabaseFactory.CreateDatabase("Sales").ExecuteDataSet("GetOrdersByCustomer", myCustomerId);
请注意，开发人员编写的代码通过名称引用数据库。实际的数据库类型和连接字符串存储在配置中。
数据访问应用程序块的依赖项
企业程序库提供的应用程序块设计为能够彼此配合使用。有时，应用程序块依赖于其他应用程序块和企业程序库中包含的代码。数据访问应用程序块具有以下依赖项：
•
配置应用程序块。数据访问应用程序块使用配置应用程序块来读取其配置信息。
•
通用程序库功能，例如规范。它提供了各种功能来公开用于系统管理的事件和数据。
默认情况下，该应用程序块使用 XML 文件来存储配置信息。修改这些信息的推荐方法是使用企业程序库配置控制台。
您可以使用企业程序库配置控制台来加密和保护包含连接字符串的数据库配置信息。连接字符串可以包含密码、网络地址及其他敏感信息。要了解有关加密配置设置的更多信息，请参阅企业程序库配置应用程序块文档。
数据访问应用程序块的设计
数据访问应用程序块旨在实现以下目标：
•
封装用于执行最常见数据访问任务的逻辑
•
使开发人员免于编写常见数据访问任务的重复代码
•
将自定义代码的需求降至最少
•
集成数据访问的最佳做法，如.NET Data Access Architecture Guide 中所述。
•
执行效率不超过 ADO.NET 的 5%
•
拥有较少的对象和类
•
确保所有应用程序块的功能对于不同类型的数据库都一样有效
•
确保在数据访问方面，无论为哪一种类型的数据库编写应用程序均相同
•
使用配置中存储的数据库连接信息
设计要点
图 1 展示了数据访问应用程序块中关键类的相互关系。

图 1. 数据访问应用程序块的设计
抽象基类 Database 定义了公共接口，并提供了数据访问方法的多种实现。SqlDatabase、OracleDatabase 和 Db2Database 类均派生于 Database 类。它们为其各自的数据库服务器系统提供方法，这包括常见功能（根据数据库的不同，其实现也不同）以及该数据库系统所特有的功能。
数据库命令和参数在数据库系统中的处理是不同的。抽象类 DbCommandWrapper 提供特定数据库类的接口定义，它将包装 IDbCommand 并提供参数处理。
DatabaseFactory 类提供了静态方法CreateDatabase，以封装创建适当 Database 对象的逻辑。通过使用工厂来创建正确的数据库对象，客户端代码就不会绑定到特定的数据库类型。
DatabaseFactory 类使用配置应用程序块来检索所需的配置信息，包括要创建的、派生于Database 的特定类的完全限定类型名和连接字符串。
该应用程序块支持动态发现参数。这种发现机制需要往返于数据库系统。ParameterCache 类允许缓存参数信息，因此可以避免同一存储过程后续调用的往返行程。
加密应用程序块简介
Microsoft Enterprise Library Cryptography Application Block1.0 版简化了开发人员在其应用程序中集成加密功能的方式。应用程序可以使用应用程序块来执行各种任务，例如加密信息、从数据创建哈希，以及比较哈希值来检验数据是否被更改。
加密应用程序块具有以下功能：
•
它可以减少编写样本代码来执行标准任务的需要，从而提供了可用于解决常见应用程序加密问题的实现。
•
它有助于维护应用程序和整个企业中一致的加密做法。
•
利用涵盖提供的各种功能区域且一致的体系结构模型，从而使开发人员在学习过程中少走一些弯路。
•
它提供了可用于解决常见应用程序加密问题的实现。
•
它是可扩展的，并支持加密提供程序的其他实现。
常见情况
开发人员经常编写一些需要加密和哈希功能的应用程序，以满足其组织的安全性要求。通常需要加密由应用程序创建和维护的数据以及配置信息。另外，还需要对用于访问应用程序功能或数据的密码进行哈希运算。
加密应用程序块通过将应用程序代码从特定的加密提供程序中抽象出来，从而简化了开发人员的工作。您可以通过更改配置来更改基础提供程序，而无需更改基础应用程序代码。它还可以封装与加密有关的常见难题（例如，加密和保留加密密钥）的最佳做法实现。
1.0 版的主要特点
Enterprise Library Cryptography Application Block 1.0 版包含以下新功能：
•
用于管理配置设置的图形工具
•
哈希提供程序的两个实现
•
简化最常见加密任务的几个方法
加密应用程序块依赖项
企业程序库提供的应用程序块被设计为能够彼此配合使用。有时，应用程序块依赖于其他应用程序块和企业程序库中包含的代码。加密应用程序块具有以下依赖项：
•
配置应用程序块 (Configuration Application Block)。加密应用程序块使用配置应用程序块来读取其配置信息，并确保用于加密的密钥是自己加密的。
•
通用程序库功能，例如规范。它提供各种功能来公开用于系统管理的事件和数据。它还提供有助于您正确使用 DPAPI 的类。
此外，应用程序块还使用 XML 文件来存储配置信息。修改该信息的推荐方法是使用企业程序库配置控制台(Enterprise Library Configuration Console)。
加密应用程序块的设计
加密应用程序块旨在实现以下目标：
•
为通常需要的功能提供简单而直观的界面
•
封装用于执行最常见应用程序加密任务的逻辑
•
为常见加密任务提供标准且一致的模型
•
确保应用程序块是可扩展的
•
确保性能影响最小或可忽略不计（与人工编写的用于实现同一功能的加密代码相比）
图 1 展示了加密应用程序块的设计。

图 1. 加密应用程序块的设计
加密应用程序块设计为具体化有关如何从运行的应用程序处理加密的所有决策。这种设计使您可以在不更改应用程序代码的情况下更改加密行为。
异常处理应用程序块简介
Enterprise Library Exception Handling Application Block 1.0版，使开发人员和决策人员能够针对发生在企业应用程序体系结构层的异常处理创建一致的策略。它的实现方法如下：
•
它支持整个应用程序体系结构层的异常处理，而不仅限于服务接口的界限。
•
它使得异常处理策略可以在管理层定义和维护，以便决策人员（可能是系统管理员和开发人员）可以定义如何处理异常。他们可以维护和修改控制异常处理的规则集，而无需更改块的应用程序代码。
•
它提供了常用的异常处理功能，例如记录异常信息的功能、通过将原始异常替换为其他异常来隐藏敏感信息的功能，以及通过将原始异常打包到另一个异常中来添加异常的上下文信息的功能。这些功能封装在名为 exception handlers 的 .NET 类中。
•
它可以合并多个异常处理程序以产生某个异常所需的响应，例如先记录异常信息，再将原始异常替换为其他异常。
•
它使开发人员能够创建自己的异常处理程序。
•
它以一致的方式调用异常处理程序。这意味着，处理程序可以在应用程序之中和之间的多种场合下使用。
常见情况
异常处理应用程序块被设计为支持包含在应用程序组件的catch 语句中的典型代码。该应用程序块允许开发人员将此逻辑封装为可重用的异常处理程序，而不是在应用程序组件的相同 catch 块中重复这段代码（例如，记录异常信息）。异常处理程序是封装异常处理逻辑和实现名为 IExceptionHandler 的异常处理应用程序块接口的 .NET 类。异常处理应用程序块包含三个异常处理程序：
•
包装处理程序。此异常处理程序可将一个异常包装到另一个异常中。
•
替换处理程序。此异常处理程序可将一个异常替换为另一个异常。
•
日志处理程序。此异常处理程序可格式化异常信息，例如消息和堆栈跟踪等。然后，日志处理程序将该信息提供给企业程序库日志和规范应用程序块，以便可以将它发布。
异常处理应用程序块可让您将异常类型与指定的策略相关联。您可以使用配置控制台来完成此项工作。策略可指定在应用程序块处理特定异常类型时执行的异常处理程序。您可以将这些处理程序串联起来，这样，在处理关联的异常类型时就可以执行一系列处理程序。
1.0 版的主要特点
Enterprise Library Exception Handling Application Block 1.0 版包含以下新功能：
•
用于管理配置设置的图形工具
•
用于开发异常处理策略的一组广泛的工具
•
在管理层定义和维护异常处理策略的能力
•
常用的异常处理功能
从异常管理应用程序块迁移
早期版本的应用程序块名为异常管理应用程序块，它用于向特定位置发布异常信息。新版本的应用程序块名为异常处理应用程序块，它提供了一组更为广泛的工具，用于开发异常处理策略。异常处理应用程序块与异常管理应用程序块主要有三点不同：
•
发布异常信息的任务不再与其他异常处理任务相集成。相反，它由日志处理程序专门处理。日志处理程序会格式化该信息并将其传给日志和规范应用程序块，以便发布该信息。
•
多个异常处理程序可以连在一起，每个处理程序都能够在传递给链中后续处理程序的异常之前执行其功能。
•
异常管理应用程序块只能对应用程序传递给它的原始异常进行操作，并且只能记录异常信息。而异常处理应用程序块则提供了一组更为广泛的功能。它可以为异常更改、取消或添加信息，以及替换经常在应用程序的 catch 语句中出现的大多数代码。
异常处理应用程序块依赖项
企业程序库提供的应用程序块被设计为能够彼此配合使用。有时，应用程序块依赖于其他应用程序块和企业程序库中包含的代码。异常处理应用程序块具有以下依赖项：
•
企业程序库配置应用程序块。异常处理应用程序块使用它来读取其配置信息。
•
通用程序库功能，例如规范。它提供了各种功能来公开用于系统管理的事件和数据。
应用程序块包括记录异常信息的异常处理程序。使用这个日志异常处理程序的应用程序需要日志和规范应用程序块。
默认情况下，应用程序块使用 XML 文件来存储配置信息。修改该信息的推荐方法是使用企业程序库配置控制台。
异常处理应用程序块的设计
异常处理应用程序块旨在实现以下目标：
•
将用于执行最常见异常处理任务的逻辑封装在最少的应用程序代码中
•
减少开发人员编写重复代码和用于常见异常处理任务的自定义代码的要求
•
允许异常处理策略在其部署后更改，并确保更改发生的同步性和一致性
•
集成异常处理的最佳做法
设计要点
图 1 展示了异常处理应用程序块中关键类的相互关系。

图 1. 异常处理应用程序块的设计
日志和规范应用程序块简介
Enterprise Library Logging and Instrumentation ApplicationBlock 1.0 版使开发人员可以在其应用程序中集成标准的日志和规范功能。应用程序可以使用日志和规范块在多个位置记录事件：
•
事件日志
•
电子邮件
•
数据库
•
消息队列
•
文件
•
WMI
日志和规范应用程序块在多个方面有助于应用程序的开发：
•
它有助于在应用程序和整个企业中维护一致的日志和规范做法。
•
它使用一致的体系结构模型，使开发人员在学习过程中少走一些弯路。
•
它提供了可用于解决常见的应用程序日志和规范问题的实现。
•
它是可扩展的，并支持格式化程序和事件接收器的自定义实现。
常见情况
开发人员经常编写需要日志和规范功能的应用程序。通常，这些应用程序必须适当地格式化事件和记录事件，不论是在本地还是通过网络。在某些情况下，您可能需要对一台计算机上来自多个源的事件进行整理。
日 志和规范应用程序块通过收集应用程序需要包含的多个最常见的日志和规范任务来简化应用程序的开发。每个任务都以一致的方式处理，并从特定的日志和规范提供 程序中抽象应用程序代码。体系结构模型可让您通过更改配置来更改基础事件接收器和格式化程序，而无需更改应用程序代码。
1.0 版的主要特点
日志和规范应用程序块是在两个早期应用程序块（日志应用程序块和异常管理应用程序块）功能的基础上构建的。该版本的日志和规范应用程序块包含了大量早期应用程序块所没有的功能：
•
无需企业规范框架 (EIF) 即可记录
•
支持电子邮件事件接收器
•
支持数据库事件接收器，而不是特定的 SQL Server 事件接收器
•
通过企业程序库配置控制台配置格式化程序
从日志应用程序块迁移
日志应用程序块的用户应该了解日志和规范应用程序块针对的多种情况。虽然当前版本是基于从早期版本获得的知识和反馈而构建的，但它在如何解决那些情况方面有了重大改变。
企业程序库版本的日志和规范应用程序块与日志应用程序块的主要区别包括以下几点：
•
它不再依赖于企业规范框架 (EIF)。
•
它使用企业程序库配置控制台中定义的格式化程序，而不是创建特定的 XSLT 文件。
•
它不再提供跟踪日志事件接收器。
•
它不再支持连在一起的多个格式化程序。相反，所有的格式化信息都包含在一个格式化程序中。
•
它不再提供加密格式化程序。
日志和规范应用程序块的依赖项
企业程序库应用程序块设计为能够彼此配合使用。在某些情况下，应用程序块依赖于其他应用程序块和企业程序库中包含的代码。日志和规范应用程序块具有以下依赖项：
•
配置应用程序块。日志和规范应用程序块使用它来读取其配置信息。
•
通用程序库功能，例如规范。它提供了各种功能来公开用于系统管理的事件和数据。
根据您向日志和规范应用程序块要求的特定功能，您可能还需要数据访问应用程序块，日志和规范应用程序块将它用于数据库事件接收器。
该应用程序块使用 XML 文件来存储配置信息。修改该信息的推荐方法是使用企业程序库配置控制台。
日志和规范应用程序块的设计
日志和规范应用程序块旨在实现以下目标：
•
确保使用该应用程序块的代码清晰而直观。
•
提供简单而直观的对象模型。
•
封装用于执行最常见的应用程序日志和规范任务的逻辑。
•
为常见的日志和规范任务提供标准、一致的模型。
•
最大程度地减少与日志和规范有关的自定义代码。
•
确保应用程序块简单且可配置性高。
•
确保应用程序块是可扩展的。
•
确保性能影响最小或可忽略不计（与人工编写的用于实现同一功能的日志代码相比）。
设计要点
图 1 展示了日志和规范应用程序块的设计

图 1. 日志和规范应用程序块的设计
日志和规范应用程序块设计为能够具体化有关如何从运行的应用程序处理事件的所有决策。这种设计使您可以在不更改应用程序代码的情况下更改日志行为。
四．日志项概述：
在记录日志时，都是创建一个日至项来承载记录的信息。每个日志项具有以下属性：
Message（必需项）
Cagegory（提供缺省值）
Priority（缺省值为-1）
EventID（缺省值为-1）
Severity（缺省值为Severity Unspecified）
Title（缺省值为“”）
五.几个重要概念：
Sink：日志记录的位置
Category：决定了你在程序中添加的日志写向何处，是通过配置来实现的。比如说我们有两个Category，第一个我们可以指定Sink为事件日志，第二个我们可以指定Sink为文本文件。
Formatter：格式器决定了日志记录的格式，通过配置实现，在进阶篇中我会重点去讲。
六．为应用程序添加日志：
为应用程序添加日志，步骤跟其他的应用程序块差不多，也是分为三步走：首先需要创建配置文件；在创建一个日志项对象，然后把它传给Logger.Write()方法。下面我们看一下具体的操作步骤：（同样我们认为您已经有了一个创建好的项目，并已经有了配置文件App.Config或Web.config）
1．运行配置工具后，选择File | Open Application打开应用程序的配置文件。
2．在Application上右击并选择New | Logging and Instrumentation Application Block。

3．日志和监测应用程序块默认的Client Settings定义了in-process distributionstrategy和LogginEnabled为True。

4．日志和检测应用程序块默认的Distributor Settings定义了两个Category（包括General和Trace）。我们看到在General下的Event Log Destination里面它的Sink为Event Log Sink，它的Formatter默认为Text Formatter。我们可以通过右击Categorys选择New | Category来新建一个Category。

]5．选择File | Save All保存全部。
6．最后别忘了拷贝目录。
"$(ProjectDir)\*.config" "$(TargetDir)"
7．在项目中添加对应用程序块的引用。
Microsoft.Practices.EnterpriseLibrary.Logging.dll
8．在程序中引用
1using Microsoft.Practices.EnterpriseLibrary.Logging;
9．添加日志：
在这之前，为程序的规范性和严谨，我们先定义两个枚举：
1/**//// 

2        /// 定义严重级别的枚举
3        /// 

4        public struct Priority
5        {
6            public const int Lowest  = 0;
7            public const int Low     = 1;
8            public const int Normal  = 2;
9            public const int High    = 3;
10            public const int Highest = 4;
11        }
12
13        /**//// 

14        /// 定义类别的枚举
15        /// 

16        public struct Category
17        {
18            public const string General = "General";
19            public const string Trace   = "Trace";
20        }
添加日志，添加日志的工作全部都由Write方法来完成。
1/**////创建一个日志项
2            LogEntry log = new LogEntry();
3
4            log.Message = this.txt_LogMessage.Text;
5            log.Category = Category.General;
6            log.Priority = Priority.Normal;
7
8            /**////写入日志
9            Logger.Write(log);
10．打开事件查看器，我们可以看到，在里面写入了一条日志信息：

11．双击日志信息，可以查看详细的内容：

至此，一个完整的日志记录我们就做完了。入门篇就到这里，另外，大家可以看一下：
http://terrylee.cnblogs.com/archive/2005/11/02/267063.html
在进阶篇里我会讲创建包含名-值对的字典，过滤事件，定制日志消息的格式，配置同步和异步等内容。
安全应用程序块简介
Microsoft Enterprise Library Security Application Block 1.0版有助于开发人员在其应用程序中实现与安全相关的常见功能。应用程序可以在多种情况下使用此应用程序块，例如，根据数据库对用户进行身份验证和授权、检索角色和配置文件信息以及缓存用户配置文件信息。安全应用程序块具有以下功能：
•
它可以减少编写样本代码以执行标准任务的需要。
•
它有助于在应用程序和整个企业中维护一致的安全做法。
•
利用涵盖提供的各种功能区域且一致的体系结构模型，从而使开发人员在学习过程中少走一些弯路。
•
它提供了用于解决常见的应用程序安全问题的实现。
•
它是可扩展的，并且支持安全提供程序的自定义实现。
常见情况
开 发人员经常编写需要安全功能的应用程序。这些应用程序通常需要执行一系列不同的安全操作，而且它们还经常与不同的基础安全提供程序（如 Microsoft Active Directory 目录服务、授权管理器、ActiveDirectory 应用程序模式 (ADAM) 和自定义数据库等）进行交互。
安全应用程序块通过收集开发人员必须执行的许多最常见的安全任务，来简化开发人员的工作。每个任务都以一致的方式处理，从特定的安全提供程序中抽象出应用程序代码并使用最佳做法。您甚至可以通过更改配置来更改基础提供程序，而无需更改基础应用程序代码。
安全应用程序块提供的代码可以在以下方案中帮助您：
•
身份验证
•
授权
•
角色管理
•
配置文件管理
•
缓存主体
.0 版的主要特点
安全应用程序块是一个早期应用程序块（名为授权与配置文件应用程序块）的增强版。此版本的安全应用程序块包含大量授权与配置文件应用程序块所没有的功能。这些功能包括：
•
身份验证支持
•
无需授权管理器即可授权
•
缓存与安全相关的凭据
•
附加的提供程序
从授权与配置文件应用程序块迁移
授权与配置文件应用程序块的用户应该了解企业程序库安全应用程序块针对的多种情况。当前版本是基于从早期版本获得的知识和反馈而构建的，但它在如何解决那些情况方面有了重大改变。
企业程序库版本的安全应用程序块和授权与配置文件应用程序块的主要区别如下：
•
企业程序库安全应用程序块包含有助于进行身份验证的功能，而授权与配置文件应用程序块则不包含可实现身份验证的任何功能。
•
现在，开发人员调用的是工厂类的方法而非提供程序管理器。这些类在应用程序块的不同功能区域中是一致的。
•
方法由提供程序提供，而非使用具有附加方法的扩展主体提供。这允许您通过自定义的 IPrincipal 实现来使用它们。
安全应用程序块的依赖项
企业程序库应用程序块被设计为能够彼此配合使用。有时，应用程序块依赖于其他应用程序块和企业程序库中包含的代码。安全应用程序块具有以下依赖项：
•
配置应用程序块。安全应用程序块使用它来读取其配置信息。
•
通用程序库功能，例如规范。它提供了各种功能来公开用于系统管理的事件和数据。
根据您向安全应用程序块要求的特定功能，您可能还需要以下一个或两个应用程序块，它们都包含在企业程序库中：
•
数据访问应用程序块。安全应用程序块的数据库提供程序使用数据访问应用程序块来访问包含在数据库中的安全信息。
•
缓存应用程序块。安全应用程序块使用缓存应用程序块来缓存安全信息，并在需要时检索它。
默认情况下，该应用程序块使用 XML 文件来存储配置信息。您可以修改此配置信息以更改应用程序块的行为。修改该信息的推荐方法是使用企业程序库配置控制台。
真正的安全信息（授权数据、身份验证存储和配置文件信息）由应用程序块中各个区域的提供程序管理。
安全应用程序块的设计
安全应用程序块旨在实现以下目标：
•
为通常需要的功能提供简单而直观的界面
•
封装用于执行最常见的应用程序安全任务的逻辑
•
为常见安全任务提供标准的提供程序模型
•
确保应用程序块是可扩展的
•
确保性能影响最小或可忽略不计（与人工编写的用于实现同一功能的安全代码相比）
•
集成应用程序安全的最佳做法
设计要点
图 1 展示了安全应用程序块的设计。

图 1. 安全应用程序块的设计
安全应用程序块在其设计中集成了通常需要的应用程序安全功能的实现。这些任务包括授权、身份验证、配置文件管理和角色管理。
3.架构分析
4.模式分析
5.工具代码
6.net的面向对象的功能