到目前为止，albian的ORM开发工作基本上那算是告一个段落了。下面的就是测试和完善。经过测试以后，我会写一篇怎么使用albian的orm完成基本的数据库增删改查工作，并且加上数据库路由功能等等。当然对于一些未经历过系统架构的XT，偶也会增加一些系统架构的示意图，当然主要还是围绕着albian的ORM和数据库路由功能展开。

      在这一阶段的开发过程中，和往常一样，还是碰到了一些问题。

      1. 在以往的开发中，泛型是我们非常喜欢的代码增强。但是对于albian而言，就泛型碰到了一些使用上的失误。albian的数据对象都是直接或者间接派生于IAlbianObject接口，而对于albian orm托管的数据对象，我们提供了数据库路由功能。数据库的路由分为2类，一类是路由到“指定”数据库，另外一类当然是路由到“指定”表了。路由数据库功能由配置决定，而路由表则由程序员提供路由算法（别担心，这个算法很简单的，只是需要根据你的业务实现，故无法有albian原生提供），而注册这个算法的时候，就是用了泛型，但是往往当我们往数据库save数据时，至少save两个object，一个是原生数据，另外一个是日志。所以我们在使用Save<T>方法时T一般都会指定是IAlbianObject。但是我们在读取是，一般读取的都是一个对象，故可以指定对象的具体类型，比如User。而albian的表路由算法是保存在一个hashtable中的，key是typefullname+routingName，这样问题就来了，注册的时候typename是IAlbianObject，而读取的时候是User，自然无法取到了。不是没有想到使用参数传入一个typefullname，当时想的是既然已经用了泛型，为什么不能使用泛型一下子搞定呢？思前想后最后还是无法得出使用泛型的解决方案。最好一火之下更改了表路由功能的全部代码，取消泛型，取而代之的是使用IAlbianObject为参数类型，增加参数typefullname参数。这样的后果就是无法对没有被IAlbianObject签名的对象进行表路由。其实真正解决数据路由的最好办法就是提供原生态的数据路由，完全脱离App，但是对于现在的主流数据库（Oracle，MySql，SqlServer），除了mysql协议完全开放之外，别的好像都很难开发；

      2.Albian Service的Id问题。用过spring或者spring.net的都有体会吧，配置注册对象时，一般都要提供这个对象的ID，在app中需要取得对象时需要传入一个id，然后由ioc容器根据id返回app需要的对象。这些本身没有错，在开始设计albian的ioc时也是这么干的，但是后来发现为什么要配置id呢？不是有interface吗？直接使用interface就可以确定一个service了，遂改掉。去掉id，一切为了简单。但是在设计albian  orm缓存时碰到了问题：用分布式缓存？还是本地缓存？还是两者皆用？最灵活的方式当然是两者兼用。而albian提供的缓存接口是同一个，所以碰到了同一个接口有两个类实现的service，用interface肯定是不行了。所以又改回来，但是为了程序的简单，当一个接口的实现是一个类时，还是可以省略id。当然从这个事情上，albian还是认为为了以后的扩展方便，最好还是配置id；

      3.mysql的字符支持问题。albian的orm支持主流的3中数据库，oracle，mysql，sqlserver。目前albian的开发工作实在mysql的环境下进行的。在第一轮测试的时候就碰到了mysql的字符集支持问题。不管你服务器端怎么调整，怎么读出不来中文。所有插入的中文全部被“?”替代了。饶头了半天，还是没有找到解决办法。只能上mysql的官方网站上找，在一个极其不起眼的地方找到了一个类似于“客户端也要配置字符集支持”的信息。好吧，加上charset=gb2312.等等，这样是有问题的。不知道是mysql net客户端的bug还是mysql服务器的bug，charset=gb2312是不假，但是必须在等号两边加上两个空格，需要配置成charset = gb2312.是不是very bt？不过这样一来，一切ok了！

      4.还有一个缓存同步问题，这个问题将会在下面的一篇中作为一个主题来讲述。albian从一开始考虑支持缓存同步到最后放弃缓存同步功能虽然经历了很长很纠结的过程，但是最后的结果还是放弃之。《放弃缓存同步》这篇bolg更多的是为了以前的兄弟们所写的，当然里面会有一些主观的想法，不一定完全是对的。但是我希望将来有一天我能提供一个示例来证明我的观点。