一、改进代码生成器：做成向导式的，通过手工干预来生成定制化的CRUD操作，而不是全自动生成不灵活的CRUD操作。要生成相关存储过程的T-SQL代码，持久实体的C#代码，以及连接存储过程和业务实体持久操作的XML元数据代码。在正式生成代码前要以向导的形式设置数据库连接字符串，生成C#业务实体的默认命名空间，生成XML元数据文件的目录名，insert持久操作的插入字段，update持久操作的更新字段和where字句的条件字段，delete持久操作所需要的where条件字段等，总之代码生成器要达到最大的灵活性，要求能人为的可视化的定制生成的代码，而不是完全自动化的生成没有太多可用性的代码。
二、所有的架构项目都编译成DLL，并做出SDK，方便开发人员使用。
三、合并CMP和WEO的业务实体类，CMP的业务实体除了业务属性外就有一个toxmlstring()方法用来在持久失败时串行化自己并记录到日志文件里以便管理员查找持久出错原因，接近于哑对象，而WEO的业务实体比较复杂，业务集是用的强类型的数据集，而不是CMP里的持久实体集（内部一个属性保存dataset来保存返回的多条数据），并且业务实体包含一定的业务方法，有的还包含支持乐观并发接口的相应属性和方法。所以要把这两个架构的持久层处理方式的优点做一些合并，在不失去方便易用性的前提下提高更多的功能。
四、数据库里的实体表都以复数形式表示，以es或者s结尾。因为表肯定存放的是多条实体记录，表名都以CRM_为前缀。
五、由于使用CMP进行持久操作所做的准备工作比较多，我想用DAAB3.1封装一个类来处理一般的数据库持久操作，比如说一些和业务关系不大的数据库操作和一些非功能需求的数据库操作，像填充数据字典下拉列表这类的，还有一些执行比较简单的标准SQL语句的操作，这些操作因为简单所有可以跨数据库，在进行数据库移植的时候几乎也不用多做什么额外的处理。
六、CMP是持久层框架而WEO是偏重业务层的框架，所以这两个框架要整和一下，让他们能相互交互和通信而且要实现统一。
七、WEO的sprocs类考虑用DAAB3.1重写，这样可以跨数据库了，而不是只针对SQLSERVER了，或者也用CMP的方式用命令映射来做一个执行存储过程的方法。也就是做一个不限于CRUD标准操作的持久方法，也是从元数据里读取持久命令和参数，而处理方式是通过工厂模式调用的，或者是oracle或者是sqlserver，总之要提供跨数据库的可移植性。
八、要让CMP支持事务（已完成）。
九、在GWTrace类里把log4net集成进去，因为没有如果做控制台程序和桌面程序的话，trace信息只能用Dbmon.exe才能查看，很不方便，但是log4net就不一样了，可以方便的生成文本日志。
十、数据库模型我正在参考MSCRM建立，一期我们只实现TES很简单的的一部分，对客户，机会，活动，联系人，以及内部员工的管理，其他的CRM研究范围尽量不涉及。咱们先从小的开始。
小节：目前为止，技术架构这里几乎一直我在这里制作，可能也项目组内成员没几个人研究过CMP和WEO，所以我写的一些改进方案有人看不太明白，也没啥兴趣。从在博客发的帖子也没人回复可以看出来，可能确实开发技术架构比较不容易吧。不过我会尽力多考虑一些的。没办法，慢慢摸索吧，只是一种尝试，但是如果方向错了的话，用心越专，离心越远，但愿我的方向不是偏的很远吧。
这阵子，我看大家也都忙了，跟项目相关的事也没人讨论了，建议也没人提了，技术也没人讨论了，等我把技术架构做出来了，然后写好业务需求分析后，大家做起来也许就有兴趣一些了，我不会让大家等的太久的哦。
