CSLA的业务逻辑

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

      他对业务对象的控制是如此的局限性&＃xff0c;以至于&＃xff1a;

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

        2。你只能。。。。

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

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

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

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

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

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

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

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

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