如标题，这里说的是CSLA框架中业务对象的分类，刚开始看到时很不理解，为什么对象还要分类呢，先来以相反的方向描述下平时大家（或者说是我的知识范围内）所应用的方法。

　　平常操作对象大都是简单的对象，这里说简单是指它只具备对象属性及对象行为这种单一功能（还有些只是数据填充器），如获取一个客户信息，我们只返回包装了客户信息数据的实体就可以，而要获取列表，只需要返回List<T>的列表，不管客户端怎样使用，对比CSLA的业务对象，它们缺乏了足够的智能性，也就是各自的职责。或者许说在使用linq2sql或者entity framework，它们有一定的智能性，可以在上下文中跟踪实体状态，以及方便的操作对象之间的关系，我也感觉它们与CSLA之间有共性，但对于一个ORM来说或许它们的责任就是以对象的形式封装数据操作，对于更多的职责来说应用起来还真有点不爽（个人感觉~）。下面就几类业务对象发表下自己的使用看法。

　　从使用角度来说，对于可编辑对象可以说是使用最广的业务对象之一，从名称中就可看得出它的职责是编辑对象信息，这里还要分根对象与子对象，对于不同级别的对象它们的操作也是不同，以根对象为例，根对象有责任编写代码从持久化里面获取对象信息以及填充属性值，而向用户暴露的属性是经过了包装过的，包装了什么呢？数据验证，身份验证，错误跟踪，撤销跟踪，状态跟踪等，客户去操作对象时在对象背后这些功能都在运转，这也是根对象的几项主要功能，框架中向开发人员开放了如AddBusinessRules类似的方法来统一管理如验证信息、权限信息，对于属性的的getter,setter来说，在2.0的版本中显得更直接，而在现在的版本中这些工作都封装在了基类中。刚才说到子编辑对象，它的职责对于根对象来说大都相同，但它并不对当前对象的数据获取作操作，而是接收来自上层对象提供的现成数据，所以它没有DataProtal_Method这种方法，它只是提供数据操作的局部方法而已，在例子中看到甚至这些数据操作方法也是由父对象来操作的。遇到的一个问题就是对象状态跟踪的准确性，特别是对于对象初始化时属性的赋值，它必须在对象内部完成，以前我们喜欢new完一个对象后再为对象默认属性赋值，因为它们没有状态，而在这里如果后期更新属性的话对象内部已经对它进行了跟踪，对于撤销操作就会有效了，所以这块需要注意一下...

　　个人比较喜欢的另一个对象类型是只读业务对象列表，它是一个列表类型，所以会对应一个只读对象子类型作为它的具体信息，这种列表业务类主要是对数据的获取以及填充列表项工作，其他的都是业务方法了，它不会跟踪对象状态（也没必要～），也没有撤销等功能，所以性能会比较好，对于只读列表绑定感觉它比较适合。这里对于频繁使用的并且更新速度慢的数据使用静态缓存感觉会比较好。

　　键值对，这个在平常用的也不少，在这里好像它与只读对象列表差不多，只是简化了类型和增加了几个基础查询方法。对于简单的数据还挺方便，好像这种数据更新速度更慢，应用缓存也是很不错，同样它只负责对象加载工作，并没有可编辑对象那么复杂，或者它是最简单的一个业务对象吧，因为对于列表对象可能会有复杂的业务方法。

　　Command对象，这个业务对象应该是最灵活，也是非常重要的一个业务对象，它的结构非常简单，但可以实现的非常复杂，我感觉这类对象让框架变的灵活的多。

　　这里所说的父、子关系，父对象并非就是根对象，这点需要搞清楚。除上面提到的几种对象外还有其他的变种形式，主要还是根据父子关系的变形，不过也很好理解。

　　自己感觉很好的应用这些业务对象来进行实际开发有一定难度，主要原因不是因为它不好，也不是因为它难，而是从根本上，也就是自己的面向对象水平还有对象设计上还有差距，如果看过DDD就会发现，它们的思路有很多共性，或许它们都是面向对象的具体体现，无论是从对于对象概念还是从对象关系处理，以及从对象职责的角度，所以自己感觉提高思想的水平是学习和应用它们的基础，这里是在了解业务领域的前提下单纯说业务对象的设计，所以与特定领域知识还是息息相关的。

　　脑门突然闪过一道光，在DDD中看到的，自己也感觉很有道理，也适合于CSLA的应用，就是这种框架的应用不是为了提高响应速度，或者说它应该是在响应速度不是最主要目的的情况下应用的框架。

　　这就是今天想到的，下次继续。
　　[ 附个个人广告：北京有招人的公司吗？工龄1.5年，C#，谢谢！QQ：496195435. ]