在Delphi下有了非常专业的、商业化的、结合UML模型的数据持久方案，例如Bold，加上自己势单力薄，于是就没有再将这个架构再延伸下去。
Borland也有一个源自于Bold的ECO，只是ECO不是线程安全的，不能应用于asp.net(这个问题直到ECO II才解决)，
在写的过程中又有了XPO和Grove作为参考，
去年年底，遇到一个侧重OLAP的项目，其中的OLTP部分采用XML文档作为数据持久载体。我忽然觉得，ECO的设计真的是望尘莫及呀！从第一个版本就 支持以XML方式持久化，而我总是受到一些不良的影响，将持久化与数据库划等号(这不能全怪我，ECO是一个全世界少有的精英团队开发的，考虑的比我全面 100倍都是正常的)。
我开始努力寻找Kanas.Net不受欢迎的致命缺陷。
其一，象用户信息这样的全局数据都是初始化时一次性加载的。在调试时IIS经常会保留上次的初始化标识，不能自如地清空对象空间，有时甚至必须停止IIS服务才能正常调试。
其二，用于检索数据的约束子机制过于复杂，很多概念非常难于理解。往往这个时候我才理解为什么Hibernate引入一个别别扭扭的HQL来，也许我自己觉得别扭的往往别人觉得很亲切。
其三，对于包装层的东西，太难于理解，扑朔迷离的。在Kanas.Net中所有的域对象代码都是自动生成的，根本无法关注域对象所应有的行为，包括一些收 集关联者的行为。于是我设计了一个包装层，将每个事务中的对象重新包装，以增强领域对象层的功能。但是这个层的太复杂，普通开发者难于接受。
Borland也有一个源自于Bold的ECO，只是ECO不是线程安全的，不能应用于asp.net(这个问题直到ECO II才解决)，
在写的过程中又有了XPO和Grove作为参考，
去年年底，遇到一个侧重OLAP的项目，其中的OLTP部分采用XML文档作为数据持久载体。我忽然觉得，ECO的设计真的是望尘莫及呀！从第一个版本就 支持以XML方式持久化，而我总是受到一些不良的影响，将持久化与数据库划等号(这不能全怪我，ECO是一个全世界少有的精英团队开发的，考虑的比我全面 100倍都是正常的)。
我开始努力寻找Kanas.Net不受欢迎的致命缺陷。
其一，象用户信息这样的全局数据都是初始化时一次性加载的。在调试时IIS经常会保留上次的初始化标识，不能自如地清空对象空间，有时甚至必须停止IIS服务才能正常调试。
其二，用于检索数据的约束子机制过于复杂，很多概念非常难于理解。往往这个时候我才理解为什么Hibernate引入一个别别扭扭的HQL来，也许我自己觉得别扭的往往别人觉得很亲切。
其三，对于包装层的东西，太难于理解，扑朔迷离的。在Kanas.Net中所有的域对象代码都是自动生成的，根本无法关注域对象所应有的行为，包括一些收 集关联者的行为。于是我设计了一个包装层，将每个事务中的对象重新包装，以增强领域对象层的功能。但是这个层的太复杂，普通开发者难于接受。
