将Enterprise Library 放到你的应用或产品中（CCBoy）
将Enterprise Library 放到你的应用或产品中
-----KickOff ,多么希望每一项目都有一个成功的KickOff
|
PublishDate: |
2005-2-17 |
|
Author: |
ccBoy(小气的神) |
|
Email: |
|
|
Environment: |
Windows 2003 Enterprise Server/IE6/VS 2003/.NETFX1.1/C# |
|
Keywords: |
Enterprise Library , C# |
|
Level: |
6/10 |
|
Catalogue: |
Enterprise Library |
问题和背景
|
当然这是众所周知的事情，几乎所有的人都知道这条消息—Enterprise Library V1.0发布了。也许其中有些是我们所期盼的，7个不同功能的Block意味着在异常、日志、数据访问、安全、加密、配置以及数据缓存(Smart Client的Offline/Online特性的支持)不同方面给以了相关的示范和代码。之前微软也在MSDN上给出了相关的一些Application Block，但是Enterprise Library意味着一个集大成，不仅结合了原来的一些Application Block，而且还扩展了新的的Application Block。 而起名叫Enterprise Library 也意味着，在企业级应用开发过程，上述的7个方面也是我们无法避免的。我想起的第一个问题是这个东西如何在我们的项目或产品中进行应用，所以这篇文章也是针对这个问题的一个思考，也许我并没能给出结论，但试图提供一个视角。 Enterprise Library(EntLib)给出了一个指导(Guidance)，而不是微软发布的一个产品，这也意味着，除了技术之外，你需要知道一些有关Enterprise Library背后的事情，这个不是秘密，你需要仔细阅读Enterprise Library的介绍。 我摘了认为重要的部分出来， |
转载请注明出处，如果有问题或建议，请发电子邮件给new2001@msn.com
|
Enterprise Library is a guidance offering, designed to be reused, customized and extended. It is not a Microsoft product. The following table describes some of the key attributes of code-based guidance offerings, including Enterprise Library.
|
|
我个人的理解 EntLib 是一个指导(Guidance)，而不是微软的一个产品。(这是最重要的一点) EntLib是代码级的，你可以基于它重新设计、扩展、重用和进行客户化。 EntLib的技术支持是通过Online和讨论组进行的 EntLib 带有源代码,你可以自由的Download 而不需要向微软购买。 所以EntLib也不是.NET Framework 的一部分，另外版本、技术和新版本的兼容性上可能更多的需要使用者自己来确定和掌握，这方面不能和微软的产品一样理解。 理论上EntLib是无限的，没有拘泥于那种架构；只要可以它可以应用于.NET的任何架构，可以使全部也可以是一部分，所以它不是一个Application Framework，而是一些帮助类；它对于任何架构的.NET应用都会有帮助。但是拥有它，掌握它并不意味着你拥了一个企业级应用的架构，它本身不是一个”Enterprise Application Framework”，也不是”An application framework that imposes an architectural style”。但它可以是你Enterprise Application Framework的一部分，并且可以解决企业应用开发中的非常典型的问题。 Enterprise Library 是Microsoft patterns & practices Library的一部分，所以它要起名叫Library J(不知道，乱猜的) 另外我也找到微软对于一些术语的解释 Patterns:Atomic solutions to recurring problems Application Blocks: Sub-system-level guidance for common services Reference Architectures:System-level guidance for common customer scenarios Guides:Guidance for broad horizontal topics such as security, performance, deployment and operations 从这里的布局你可以非常清楚的看到微软对于Patterns、Blocks/code 和Guides的分类。那么也可以清楚地看到Enterprise Library的位置，显然它属于Guidance，唯一不同的是它不仅是一本书，而且还带着代码。这个Guidance不仅有”理论”而且更多的是”实践”J 当然MSDN也出过Reference Architectures — Enterprise Development Reference Architecture(EDRA) 目前GotdotNET Workspace中排名第二，但它不是基于EntLib的。有关基于EntLib的Reference Architectures也早就有了---ACA.NET，只是没有公开源代码。 (The Avanade Connected Architecture (ACA) is a set of frameworks created by Avanade starting in 2000. ACA DNA was the initial release for COM based applications. A few years later, ACA.NET was released and now has become the foundation of Enterprise Library. During the year-long process to create Enterprise Library nearly every line of code has been scrubbed, modified, rewritten or replaced. The current release of ACA.NET v4.0 has been rebuilt using Enterprise Library 1.0 as its core. ACA.NET extends the core blocks of Enterprise Library with new innovations like service and aspect oriented architectures.) [上述英文引自Hisham Baz的WebLog] 好了，认识和理解是第一步的，之后我开始计划做些什么。 既然EntLib不是微软的一个产品，那么对于EntLib的代码就必须由我们自己来维护，而且保持产品和版本特性。如果要应用到我们的项目中，由于EntLib的性质，很多的时候它会成为比较低层和公用的部分，也意味着可能在我们的多个项目和产品中。那么可能会出现变更和不同的版本，另外有可能Microsoft patterns & practices Team也会发布新的版本，所以EntLib也更像我们自己的项目的一部分并由我们自己慢慢维护起来，某种程度上，如果将它加入我们的项目和产品中，那么也意味着它将进入到我们的SCM流程中。 第二，对于开发人员来说，也应该有一个相对严格的使用流程，也许今天我们项目中的安全、加密或配置模块和网上下载的EntLib是一样的，但是也许六个月后，我们就有了修改或有了自己版本的EntLibX，那么这时候的EntLibX和我们项目和产品中其他公用模块并没有其他区别。 然后我想得了下面的一些要做的 1. 首先要确定EntLib在我们的项目的版本，对它做一个基线，源代码配置到我们自己源代码库的一个分支，可能有专门的一个小Team负责EntLib的部分。其他的程序员以二进制的形式使用EntLib。 2. 准备培训相关的活动或材料，除了培训之外，对使用到的EntLib的代码进行Code Review 3. 一定会有人问EntLib的性能如何？--(啊，这是一个好问题J)，所以要考虑和评估性能问题，因为EntLib已经成为我们应用或项目的一部分，那么我们在考虑应用的性能时，需要增加对EntLib部分的考虑 之后我想到了强名(Strong Name)，想到了GAC，而我打开EntLib的项目，看到它也没有做强名。后面想到的景象是将整个Enterprise Library 做一个强名，并且确定其版本号。重新编译后，源代码入代码库，二进制的部分发布到一个目录供程序员和相关的开发人员程序使用 |
我的ToDoList
|
步骤如下 1. 安装EntLib后备份原来的代码主要是\src 和\bin目录 2. 下载Patch 1462 并且更新到原来的代码 [0] 3. 用sn.exe 生成一个强名的Key [1] 4. 使用Visual Studio 2003打开项目文件EnterpriseLibrary.sln 5. 修改每个项目的AessemblyInfo.cs [2] 6. 重新编译项目，成功，关闭Visual Studio和EntLib项目 7. 生成一个批处理文件，用来安装Assembly到GAC [3] 8. 在命令符方式下执行Microsoft Enterprise Library\src\BuildLibrary.bat [4] 9. 执行步骤7生成的批处理安装EntLib V1.0 Assembly到GAC [5] 10. 修改注册表，定位Assembly的引用 [6] 11. 进行测试，修改\QuickStarts中的.sln文件，并挑选相关的依次运行 [7] 12. 将\bin目录的部分复制到另外一个目录\Release目录 13. 根据步骤7的处理文件，重新生成Install/Uninstall 到GAC的批处理文件，并将它放到\Relese目录 14. 将步骤10的操作产生一个批处理文件，复制到\Releease目录 15. 备份步骤2产生的密钥文件 16. 整个项目进源代码库，\Release目录发布给项目组的开发成员 |
相关的一些说明
|
[0] 补丁 关于1462补丁，Scott的WebLog 或 gotdotnet上可以下载到 Hisham Baz的WebLog -- Getting Started With Enterprise Library 依然是首选的必读文章 另外EntLib Required Post-Installation Step讲到内容，需要你自己做出判断。 [1] 在\src 目录 sn –k EnterpriseLib.snk (当然如果你的应用或项目已经有了自己的Key则可省略) 创建一个批处理文件，里面可以就只有一句话，并且运行 sn -i EnterpriseLibrary.snk MSEnterpriseLibaryContainer 这样我们在强名的时候就可以不使用AssemblyKeyFile选项，因为它总是需要路径，DailyBuild的时候，经常会为这个相对路径搞来搞去。 [2] 在 EntLib项目中有一个GlobalAssemblyInfo.cs 文件，每个项目都有一个自己的AssemblyInfo.cs GlobalAssemblyInfo.cs 保存着编译配置、公司/产品、版权声明和版本号 每个项目自己的AssemblyInfo则保存自己的Assembily名和CLR权限设置 我测试的时候，是打开每个项目在每个项目的AssemblyInfo中加入强名信息(这可是个力气活38个项目文件一个个打开，真笨啊)，最后我发现其实不用，加在GlobalAssemblyInfo文件中更方便 只用加一句 [assembly : AssemblyKeyName("MSEnterpriseLibaryContainer")] 而不使用AssemblyKeyFile选项，然后保存项目，重新编译项目，确定我们没有误修改。 [3] 主要是生成一个Install的批处理文件，将我们编译好的EntLib加入到GAC中 这个主要是用Gacutil.exe 我发现EntLib原来目录下的InstallServices.bat 不错，然后拿过来修改一下，就可以变成非常合适的工具InstallAssemblyToGAC.bat。然后再修改一下就可以生成一个UninstallFromGAC.bat，这两个批处理修改路径之后还可以供开发人员使用二进制的EntLib时使用 这里还有的一个可选操作是执行InstallServices /u ，我想这是建议的，之后我们要重新编译EntLib项目和注册，所以最好将之前InstallServices做的工作Uninstall [4] 就非常简单了，EntLib提供一个批处理专门做这个事情- BuildLibrary.bat 还有一个MSILibrary.bat也做同样的事情。只是MSILibrary.bat编译遇到错误不会暂停，其他功能就一样了 [5] 之后就比较简单了，运行之前生成的批处理将相关的EntLib编译结果Install到GAC中 除了InstallServices.bat中包括的Assembly，我又增加下面一些Assembly： Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll Microsoft.Practices.EnterpriseLibrary.Logging.Sinks.Database.dll Microsoft.Practices.EnterpriseLibrary.Security.ActiveDirectory.dll Microsoft.Practices.EnterpriseLibrary.Security.AzMan.dll Microsoft.Practices.EnterpriseLibrary.Security.Cache.CachingStore.dll Microsoft.Practices.EnterpriseLibrary.Security.Database.dll Microsoft.Practices.EnterpriseLibrary.Security.Database.Authentication.dll 之后再运行InstallServices.bat 这样新的Enterprise Library就算安装上了。 [6] 是在Visual Studio能够寻找到EntLib 和方便添加引用(可选) 这里主要是在AssemblyFolders 中添加Enterprise Library的地址，可以参考MSDN Library或Johan Danforth的WebLog. 这样就方便多了，免得多次打开浏览窗口，一个目录一个目录的找了。最重要的是我不能忍受带着EntLib的源码做自己的应用，另外如果没有强名，每个项目都要将EntLib的Assembly复制到本地，这是多么大的浪费J，之后将这个注册表的条目导出，修改之后复制到\Release目录供其他人员使用 [7] 这是编译之后的进行的验证性测试，你说BVT也好，冒烟也好。我就选用QuickStarts中的例子了。这个过程中我发现一些好处，也发现一些不方便的。 首先我打开每个项目/解决方案，然后用Sava as…另存一个新的解决方案，然后 Remove原来Application Block的代码/项目引用，将他们移出QuickStarts的解决方案，然后再添加GAC中EntLib的引用，保存解决方案，然后Rebuild, F5，有时会发现运行失败!!#$ ，仔细一看众多的相关文件，发现许多配置文件是这么写的，导致找不到这些Assembly。 type="Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings, Microsoft.Practices.EnterpriseLibrary.Caching” 因为FX/CLR期望的是类似这样的 type="Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings, Microsoft.Practices.EnterpriseLibrary.Caching, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c34455a7XXXXXXXX"> 而我发现一些QuickStarts的例子中也是这么写的，就是最后PublicKeyToken=null，所以推测之前EntLib也是强名的，也许发布的时候去掉了。 不过我发现一个更简单的方法，就是你先不要编辑这些配置文件，用Enterprise Library Configuration 工具重新打开一次，然后保存。如果你是强名的，Enterprise Library Configuration就会自动将Version, Culture, PublicKeyToKen给你加上。不过强名之后，运行QuickStarts中的例子是非常有趣的，这个是后话，不说了J
[?] 再之后的就是软件配置或SCM的事情，后面的步骤是让开发人员可以很快地安装和设置好有关EntLib的部分，而不是所以的开发人员都要下载、安装、编译EntLib这样繁琐和重复的工作。 而是简单的从我们自己的代码库上下载，运行下载的批处理即可完成EntLib的设置。 对于EntLib编译的部分，我想如果你之前已经在使用任何的DailyBuild系统，那么只要将其加入到你的DailyBuild系统，那么EntLib和你的应用没有差别。 |
应用、版本和集成相关的使用模式
|
这里临近文章的尾声，我想多讨论一些EntLib使用的模式上。 下面我假设的一些使用场景： 方式一: 继承迭代型。 这是你的应用和项目是刚完成设计，准备基于EntLib进行构建，也就是说是新建的项目，并且是基于EntLib，那么最可能的方式是EntLib的代码就作为你迭代的基础代码，你就在此基础上增加你的业务模块或是将EntLib以源代码的方式，加入到你的项目/应用树中。随着项目/应用的发展，已经没有或分不清EntLib和你的代码了。即使微软出了最新的版本，你发现其代码已经修改过了，这个补丁可能不适合或不需要了。 方式二：集成扩展型。 这是说你的项目已经完成，刚刚开始或已经使用了EIF，Log4net，你现在想用EntLib的配置、日志或加密等等模块进行替换其中的一部分，然后其模块跟随你的应用或项目版本进行变更或扩展。这里也有两种方式，一种是基于代码方式的集成和扩展，一种是基于二进制方式的集成和扩展。 方式三：分离演化型。 这是说你根据你的架构选择EntLib的部分来解决你应用/产品的问题。所有的使用方式是二进制的方式，EntLib和你的应用/产品是分离的，它可能有自己的版本和Team在维护。当然这个Team可以使确实存在或是虚拟的。EntLib根据这个Team的方式进行扩展和改动，当然也会考虑你的要求，但是这里强调的是松耦合的分离模式。你的应用/产品可以不断发展，你的EntLib也可以不断发展和演化，但两者的特性和代码管理以及版本策略上是分离的。 方式四：混合型。这种方式是除了上诉三种方式之外或混合的方式，这主要是加上时间的因素，因为可能你这一次使用继承迭代型，当你完成这个应用/项目后，将可以重用的部分抽出来形成一个增强型的EntLib，然后在下一个项目使用分离演化或集成扩展型。 下面的图是各种使用方式都需要了解的EntLib各个Block的依赖关系。看得出来配置块最基础，而Security和Exception最复杂，依赖最多。依存关系对于方式一几乎是透明的，对于方式二影响最大。对于方式三来说，影响很小。 [图片来源Microsoft Enterprise Library Document] 主要的三种方式各有优点和缺点。 1. 方式一继承迭代型，开发时间较短，不用考虑版本和重用性，不用维护版本特性。 2. 方式二集成扩展型，介于方式一和方式三之间，讲求重用和原有系统的稳定性。属于策略型，如果是二进制方式的使用，则和方式三非常相似。但是没有版本策略，如果是代码方式的使用，几个项目后各有变体产生，丧失重用性和重复劳动。 3. 方式三分离演化型，讲究重用性和兼顾版本策略，不好的是可能需要专门的人员维护。 本文提及的重新编译、强名对于二进制方式的使用和扩展是具有建设性的。尤其是方式三(分离演化型)和方式二(集成扩展型)的二进制使用方式。 我希望将Enterprise Library写成一个系列的文章，当然如果时间允许，如果我们的项目和产品组都使用了它J，这一篇文章主要是针对EntLib的配置、安装和使用进行一些思考。我认为一些视角和事项是我们使用前就应该思考和有所了解的。希望这些对你有所帮助。 文章相关的讨论，见下面的申明信息。 |
本文原创，所有文字和图片版权所有。未经授权请勿传播、转载或改编。
|
特别： 文章观点，仅代表个人观点和立场，对于文章所含信息的适用性，不作任何声明。本人对其变化不带任何性质的保证。本文原创，所有文字和图片版权所有。未经授权请勿传播、出版或改编。 转载请注明出处并保留该声明，如果有问题或建议，请发电子邮件给new2001^msn.com 欢迎访问我的主页：www.dotNETTools.org 该文章相关的讨论请点击这里 |
