CSLA的业务逻辑

      在使用CSLA之前，一直使用nettiers，也许是因为习惯原因，一直觉得CSLA太不成熟了，至今唯一觉得好用的是他的dataport数据门户，最讨厌的是他对业务对象的操作控制，基本没有办法使用。

      他对业务对象的控制是如此的局限性，以至于：

        1。你不能从列表移除一个业务根对象

        2。你只能。。。。

 

        虽然，所有的困难都是可以克服的，但这并不能做为CSLA的“垃圾”业务逻辑的借口

        子对象－》父对象 是其中最令人讨厌的业务逻辑设定

        1。由于CSLA对父子对象的设定太过死板，我们不得不将所以的业务对象设置成即有父对象操作，又有子对象操作，以便在不同的场景中使用它们（当然，你可以为每个表创建多个业务对象，但这也不能成为“不垃圾”理由）

        2。业务对象使用不同的操作如果不能算设计中的垃圾之作，那数据门户只能对父对象进行ROOT就可能得算一个了（地雷啊）

        3。子对象在使用数据门户的情况下，只能有父对象操作，真正的成为了一个子对象！

        4。还有可能遇到更多的问题

       

        个人觉得，虽然有时候我们可以划定父对象与子对象，就像男人上男厕所，女人上女厕所一样，

        但是大部分时候，还是需要业务对象根据我们的划定来区分，如果我需要他是子对象，他就是一子对象，拥有子对象的操作行为逻辑，如果他是根对象，就应该有跟对象的操作逻辑，大多数时候，我们压根就不需要区分的那么清楚，我们只要在需要的时候，把业务对象当作适当的对象获取就可以了，CSLA做为框架应该实现业务对象的管理，包括父子对象关系，而不是如此简单的将父子对象区别对待

 

          表达能力有限，文章混乱，只为记录CSLA中最重要，却最不贴近实际的问题