Step by Step-构建自己的ORM系列-配置管理层

继续这个系列，当然我也在写这几个系列的过程中，对ORM这个系列中的原来的实现的想法有了新的认识和改进，当然这些都不是说是很先进的思想或者认识，也可能是大家见过 的思路吧,希望后面我能在写设计模式系列的过程中，穿插讲解ORM系列，当然我的这个构建的系列，也只能说是很简易的，自己平时开发个小应用工具或者什么的，可能用他， 因为是自己开发的嘛，毕竟使用起来还是比较顺手的！符合自己的操作习惯嘛。         当然我写这个系列的过程中，也会有自己认识偏激的地方，或者思路不正确的地方，还请大伙多多指出和批评。我也是在我目前的项目中学习到了很多的宝贵的经验，其实 我们应该能看到ORM给我们提供的方便和不便之处，我们取其精华，剔除糟粕，不过这真的很难。这块可能还需要大牛们多多指点。        对于上篇文章中，我们提到过几个问题，然后经过我与不少朋友之间的交流，得出了一些不错的意见和想法，这里分享一下总结后的内容。        1、提供一个通用的查询方法，可以动态的返回列。        对于这个问题呢，我们经过商讨考虑了最后最可能的情况如下，我们借助于平时我们知道的params的动态行来进行返回，可能的实例代码如下：       当然这里给出的代码不一定是最好的，当然这里给出的是目前个人认为不是太差的方案了，如果您有好的方案请留言，谢谢您了！       2、我们如何在表现层中更好的调用我们的查询层服务方法：       这是我们上篇给出的一个实现方式，后来思考下，这样的方式其实也不是最好的方式，经过思考，我们将上面的传入查询条件的语句进行封装，修改成如下形式。       第二步，我们提供参数辅助类：      第三步，抽象工厂，负责创建上面的辅助类对象实例     最后，给出具体的调用测试代码： 上面我们讲述了，上篇中解决的几个问题，相信这类的问题，在您的项目中，应该也是很常见的，当然，如果您有更好的方法，请您反馈，得到您的反馈是我最大的动力，谢谢！

        本篇将会开始讲述ORM层中可能应该要提供的配置管理层的相关职责和功能，我们都知道目前我们在很流行的ORM框架中，都会为了应对不同程度的变化，我们为为了提 高我们的ORM框架的灵活性或者适应性，我们通过配置文件来应对这样的变化，我想NHibernate是将这个方面应用最好的框架之一了，我呢，也是最近才开始看NHibernate的框 架使用，也是参考博客园中一些很好的教程。         本文将会结合配置管理层应该提供的相关功能和ORM如何与配置管理层相结合来说说吧：         我认为的在ORM中应该提供的配置管理层来进行扩展的可能功能列表如下：         1、对于底层ORM中的线程池的配置管理。         2、对于底层的ORM中的数据连接池的配置         3、ORM提供的对象工厂的程序集配置。         4、ORM提供的缓存服务的相关配置信息。         5、ORM中的底层对于多模式的支持。         6、ORM的对于服务的启用与否的控制。         7、配置ORM的其他相关参数，比如是否启用事务，是否启用分布式等等。

       1、开篇。        2、摘要。        3、本文大纲。        4、ORM之数据访问层分析。        5、本章总结。        6、系列进度。        7、下篇预告。

          4.1、对于底层ORM中的线程池的配置管理

         ORM底层应该对多线程并发的时候，做一个考虑，比如我们是否使用系统自身提供的线程池来控制互斥资源的放问，来控制并发，这个时候，我们可以进行控制，并且可 以控制线程池中的活动线程最多可以同时运行的最大并发数量，包括资源持有的最大时间，还有就是等待超时的时间，线程的生命周期等等。这个我们怎么理解呢？就是如下的过 程：

          4.2、对于底层的ORM中的数据连接池的配置

        数据连接池的主要作用是什么？我们必须搞清楚，所以才决定有没有必要使用这个连接池，一般来说，系统的使用连接数超过2个使用连接池就是有必要的，因为我们每次 与数据库建立链接都需要耗费很多的资源，如果我们能够在不使用数据库服务的时候，我们把这个链接占用的资源都释放掉，那么下次我们访问数据服务的时候，我们又需要创建 新的链接，这样每次在创建链接的时候，就消耗了太多的系统性能，我们是否能够将这些创建好后的链接缓存起来，放在数据库链接池中，这样如果我们发现数据库连接池中的有 空的链接存在，我们就直接拿来使用就好了，如果数据库连接池中的资源都在占用，那么我们可以有一个队列来缓存我们要执行的任务队列，通过很好的控制管理，我们来控制任 务的异步执行。我们来看看数据库连接池的情况，应该和线程池在处理上差不多：

          4.3、ORM提供的对象工厂的程序集配置

                 我们提供一个配置项，完成对抽象工厂的配置，参考我们之前讲述的设计模式系列中的抽象工厂的配置，完成通用对象的创建。如果您还没有看如何配置，请查看如下文章：                 如果您有更好的意见或者想法，可以提出来，谢谢！

          4.4、ORM提供的缓存服务的相关配置信息

         缓存服务，我们知道，ORM的性能损失就是在对象关系映射的相互映射中的损失，由于，我们这里又是采用特性+反射来做的，那么无疑，我们如果不缓存关系映射的过 程，那么我们的ORM设计出的效率，肯定是不是让我们很满意的，当然数据量很小的情况下还是可以的，但是一旦数据量上升，那么将会是灾难。           我们提供的缓存可以在将对象映射为数据库表字段的这块，不然每次进行持久化操作的时候，我们就要反射一次，那么对于经常操作的对象，无疑是个巨大的性能损失， 我们可以考虑将这块的映射关系，缓存下来。           我们的缓存服务还可以对自动生成SQL语句的时候的缓存，主要体现在，我们不用每次创建SQL语句的时候，我们都反射来做，我们通过缓存来完成。           我们的缓存服务还可以是对数据的缓存，比如我们底层设计好的缓存策略，为上次模块提供支持，比如我们提供底层的数据缓存，通过提供相关的配置，我们可以提供类 似iBATIS提供的缓存形式。我们可以配置缓存的过期策略，和引起缓存变化的原因等等。           具体的配置形式：           还包括一些底层参数配置的缓存，由于有些项我们每次读取配置文件可能效率上出现在文件的IO操作，这个时候，我们可以考虑把配置信息缓存起来，对于一些不是很经常变化的内容。           对于配置文件的操作，我们可以考虑图形化的操作界面，为用户提供更好的使用方式。

          4.5、ORM中的底层对于多模式的支持

          这里提出的多模式，也是参考一些对于内部会议的一些思考，比如说，我们的ORM对于debug模式和其他的release版本提供的功能是不是应该不一样。或者说ORM的适应性应该更强大。           我们通过配置项来提供，我们内部底层的ORM提供对不同的模式的支持，包括我们底层ORM的可调式的设计和其他方面的设计思想。           我们知道对于底层框架的测试是个很大的工程，需要不断的测试，不断的优化，才能提高ORM的稳定性和性能，所以我们可能前期考虑的比较多，那么我们才能在ORM的 设计中考虑到更多的适应性和扩展性，只有这样，我们的底层测试工作才能开展的很好，也就能满足后续的不断的变化需求。

          4.6、ORM的对于服务的启用与否的控制

          ORM的服务的启用禁用，主要是体现在我们底层的一些功能的设定，比如说是不是动态启用日志功能，或者说是不是启用底层的底层验证功能，还包括其他的一些AOP的 相关设置，包括一些配，启用禁用序列化的服务等。对于查询服务中的是否启用缓存分页，包括缓存的替换方式，是增量叠加还是完全覆盖的方式等。

          4.7、配置ORM的其他相关参数

          ORM的其他配置项，我理解中的应该还包含如下的配置服务：     具体的详细内容，我估计我也就没有什么特别详说的内容了，大家一看就知道了。

        本章都是关于配置的相关内容，本文并没有提供出具体的代码实现，由于对于配置文件的操作， 其实网上有太多的例子了，我这里也不班门弄斧的给出大伙了，网上有很多 更好的例子，我这里就不给出操作代码，VS内置了很强大的操作配置文件的类，我们可以简单的包装下即可满足我们的要求，当然如果满足不了，那你就重新扩展功能吧，我上 面只是给出了ORM可能提供的功能配置项，也没有给出配置文件的具体格式和内容，当然如果我上面有什么遗漏或者没有考虑到的地方，还请您多多指出，我会补上去，谢谢您的 提醒！

      下篇我们将会开始讲述对象映射层中的具体的缓存及相关的过期策略，还包括一些底层ORM对象映射过程中的可测试的设计及可跟踪的设计，希望可以对大家有所帮助，如 果您有任何的已经和建议，请您留言，由于本人水平有限，错误之处在所难免，还请大家多多指出！ 本文转自 hot的fans  51CTO博客，原文链接: http://blog.51cto.com/2435232/590961