albian经过了一个星期的开发，目前一条主线已经完成了。能完成简单的单实体insert操作，并且已经支持了database routing。就目前的开发进度，语句不带cached的albian orm会在一个半月之后完成。
在这段时间内，开发碰到了一些问题，自己也得到了一些启示。
1.首先是databse connection pool问题。一般net链接的都是sql server数据库，而一般我们需要使用connection pool的时候，我们经常在connection string加入pooling = true，max poll size 和 min pool size来控制。一般我们也能如愿的使用上pool。但是当你面对着异构数据库时，这些配置就会出现问题。我在实验mysql驱动链接database时，加入了pooling的配置就会无法创建connection，而albian原则上是需要提供异构数据库支持的，那么别无选择，这个时候就要自己实现connection pool。幸好不是很难，自己实现了一个。有兴趣可以查看源代码的Albian.Pool和Albian.Pool.Imp。再说一句：以前飞客在线的某框架自己实现了connection pool，很多同事都无法理解，现在我算是理解了初衷。看样子是要自己写一下才有发言权，否则纸上谈兵真的没有意思；
2.关于cached。在albian中，一个程序集中使用到很多的cached。挣扎了很久，终于决定牺牲代码的可维护性用来增加程序性能。在Albian.Persistence.Imp程序集的cached文件夹中，到目前为止一共有4个cached的代码，分别存放不同对象的缓存，其实这4个可以合并成一个cached，但是为了性能和看上去的“清爽”，还是放弃了共用；
3.分库分表的实现。首先考虑的是事务问题。当你提交多个请求到不同的数据库时，那么就要用到分布式事务。MSDTC？如果你的oracle或者mysql在linux上呢？所以，这是必须解决的一个问题。不过树死人活还是有道理的。albian设计了一种“伪分布式事务”。当我们在提交数据库访问时，albian会把此次访问设置成一个task，task中会有很多个storagecontext，每个storagecontext会对应一个数据库链接。这样，albian会在根据你的实体和配置文件解析你的意图，并且组合成storagecontext，这样最后就会变成一个task上对应着很多个数据库操作的命令，然后我们在每个storagecontext打开数据库连接，并且带本地事务的执行命令，最后由task的context来决定事务是要提交还是回滚，这样就可以即做到分布式事务，又可以对异构数据库的支持。唯一的不足是可能会产生数据的不一致性（如果网络非常不好的话），但是对于分布式环境而言，这样的数据损耗还是可以接受的；
项目前景：
就目前的情况下，下2个星期的工作主要还是在于albian的orm上，最少要完成对于数据库的DML的操作。完成DML后，开始设置albian orm中最大的症结问题：查询。albian将会提供一个人性化、在一定范围内灵活、快速的查询功能。