答haoyuhai问

我初期接触CSLA时也有象你一样的感觉，不过深入下去研究，发觉优点还是大于缺点的，毕竟到现在为止，还没有遇上十全十美的框架。

1。csla将业务逻辑层和UI层紧藕合在一起，在设计业务类时，必须要考虑界面的情形，这种依赖关系应该是有问题的。

CSLA的业务类，我用下来没发觉和UI有太多的纠葛，他是通过IBindingList提供UI层的数据绑定。不知道你说的依赖关系，是不是指业务类中对数据的有效性、合法性等等做了校验的动作？如果是这个的话，我认为这是合理的，因为这些也是业务逻辑部分。

2。数据绑定是很强大，但是数据绑定应该只限定于UI层，不应该在设计业务类时考虑这些，而且数据绑定不够灵活，应该提供非数据绑定的方法。

“数据绑定”确实将UI和业务类捆绑的蛮死的，不过带来的好处是，UI的开发量很少，比如：界面数据感知控件排布好后：

在show事件里usersBindingSource.DataSource = Users.Fetch();即可填充数据；

CancelButton事件里：_users.CancelEdit();即可恢复数据；

SaveButton事件里：_users.Save();即可提交数据；

在界面组件中的代码量很少，基本都是些用户体验方面的代码，比如“焦点如何随着操作进程进行自动跳转”等等之类的，而真正的业务逻辑都是在业务类中实现了。从这点来看，CSLA的业务类实现了非常高的内聚。

对于耦合，我的理解有两方面需要考虑的，第一是横向的，也就是业务组件之间，是否实现了松耦合，这点应该是业务分析阶段重点考虑的问题；第二是纵向的，也就是逻辑分层和物理分层，这些是框架需要考虑的，如何提供好的模式。我认为CSLA这点做得不错。

逻辑分层和物理分层不是一回事，也不是一一对应的。也就是说“UI-Business-DB”和“客户端-应用服务端-数据库”不是一一对应的关系。我认为Business恰恰根据负载均衡的需要分布在了“客户端-应用服务-数据库”三处地方：

在客户端，Business叫“工作间层”基本处理数据校验等规则；

在应用服务端