这次框架设计前后做了3个版本，最初用领域驱动做的。后来怕大家接受不了，改成了WCF的数据服务做底层交互，放弃了领域驱动。最后又因为项目时间紧，学太多新东西可能影响到项目的进度和年终奖金。最终变成了现在的架构模式。要是说目前的架构和以前有什么区别，主要有以下3个方面：
- 放弃了Factoty，没有调用WebService还是BLL的概念，统一都是调用WCF，由WCF调用业务逻辑的。
- 这样做主要是因为签出Factory、WebService生成自动生成实在太慢了。中间又有人签出什么的，很容易导致得版本后编译报错。
- 还有就是客户的带宽问题，以前因为带宽问题，部分情况下走BLL会比WebService快很多，但使用了压缩技术后这个问题已经解决了。
- 原先项目数过多，一个BLL一个项目，现在对BLL和表现层做了合并，将原来的50多个项目做了合并。同时将一些不太会发生代码变更的项目挪到了Tools解决方案下
- 将原来的BLL进行了层次梳理，变成了Service、BLL、Engine、EngineService。这部分哪些表的操作，放在哪个项目下，目前只有大致概念，不详细。会列一份清单给大家参考的。
- 对公共方法进行了整理，将原来的BusinessTool去除了，按照功能将其放在了Helpers目录下。
框架无所谓好坏，能帮大家节省些开发时间，减少冗余代码应该就算成功了。听说好的框架可以减少80%的重复代码开发。感觉上这次的框架设计，使得表示层的代码已经比以前减少很多了。业务逻辑方面还是主要靠各个小组的开发水平了。虽然有一些规定，但由于Linq没用上，核心逻辑写在engine里，肯定还是大段看不懂得代码，能用存储过程，还是尽量用存储过程吧。对于没用上Linq我还是深以为憾的。