（把时间回到昨天中午）刚吃完午饭，吃边边在想早上下载的最新版本的CodeSmith（5.2），看它生成的CSLA框架代码的情况，搞了一阵子，出现很多异常，还以为是软件出毛病了，逛了他们的E文说明才发现比2.0多了很多步骤，最后还是搞定了，令自己大吃一惊，新版本(3.8)中的东西比2.0里面多了很多，这里是指代码生成时的代码量多了很多！！类也成了嵌套式的了，把业务、属性、数据门户等通过部部分类的形式分开了，而且附加了很多零碎操作，比如OnFetching这种的部分方法，或许是因为现在的客户端技术太多了，反而显得框架有些零散，不过如果普通使用的话删掉还是可以。
原本以为2.0的思想会搬到3.6/3.8里面，确实是搬了，不过看框架源码里面改动的挺大，更智能化了，特别是对于属性的操作，封装的真是厉害，跟踪了好几次才搞明白，没有2.0里面那样简洁了，突然感觉不如2.0里面爽...
经过开发药品管理这个小系统，突然发现思想被束缚了，与刚开始接触petshop式的普通三层那个时期一个感觉，好像找到了最好的思想，最为理想的解决方案，对于csla来说，无论是它对“客户”开放的接口量，还是对于业务处理的思想，对于属性getter,setter的充分利用，业务验证的创建到业务的CheckRules的过程，数据门户的封装与处理，通过配置方式配置多台机器的分布式方式，还有好多好多的功能，很强大，不过对于业务对象的设计来说好像有一点问题，或者没有想出好的解决方案，对象里面存在继承关系，对于这个框架里面不知道如何来解决这种继承，不过对象组合是没有问题，典型的就是父子关系（无论是单对象还是集合对象），父对象有责任对子对象进行数据加载（也就是说子对象的数据来源于父对象提供），也拥有对子对象进行跟踪的权力...
刚想到个问题，出于DDD思想，一般情况下它提出业务数据操作与数据库数据操作的分离，也就是说，业务数据与关系数据不会一一对应，更狠点说业务对象不关心数据是怎样处理的，这些处理都委托给基础设施层来搞定，这里就存在一个问题，就是业务对象的数据与关系数据的映射，通常情况下我们实现时是通过SQL查询或者LINQ2SQL、EF等来实现，查询出来后就直接映射到实体上，而要解决这种不对应关系就要通过map来把关系数据再次映射到业务数据，这么一来，数据的中转过程多了一步，无论是数据的读取还是更新操作，性能问题会怎样呢？对应到CSLA里面也是如此，没有测试过，只是担心，尽管数据操作会通过移动对象的方式放在服务器来处理，或者说这点根本不算是性能耗费，还是说这也是一种性能与扩展之间的平衡选择呢。。
当然，对于某个框架或者某项技术来说说肯定是要把它放在一种，或者说是一类应用领域中，与设计模式那样，用在了正确的地方才显得出它的优势。
（文章内容没有"科学依据"，仅是自己的随想）