答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叫“工作间层”基本处理数据校验等规则；

在应用服务端，Business叫“业务处理层”基本处理数据的采集、业务算法和数据的持久化等过程；

在数据库里，Business叫“资源层”一般以存储过程形式存在，在面向对象开发中弱化了它，主要做些大批量的数据处理，以提高应用系统的整体性能。

所以Business层，由于所处的物理层不同，而承担的职责是不同的。但他们处理的又都是一套数据，都是业务逻辑，那么最理想的方式，就是将数据及其业务逻辑放在一个类里。这对于开发者、测试人员、维护人员来说，都是有很大的好处的，大家对业务组件的关注点就这一个，对于开发过程的管理也省便了许多。虽然，代码形式上是放在了一起（CSLA框架还是限定了区域，自己也可以采用注释的方式进行划分），但运行期却不一定运行在一个物理空间里。

CSLA提供了很好的一套模板，工作间层、业务处理层，分得清清楚楚。这是实现高内聚的很好案例。

3。移动对象的概念，试图屏蔽对象是本地的还是远程的，这一点在分布式程序设计时也是有问题的，因为分布式程序设计与本地程序设计在原则上区别是巨大的。

由于业务类将“客户端”和“应用服务”里的业务逻辑放在一个类里，所以在物理分层中需要考虑这些问题。

CSLA利用“数据门户”将调用协议进行了封装，达到了透明化，下面这段代码非常重要：

private static DataPortalClient.IDataPortalProxy GetDataPortalProxy(bool forceLocal)

    {

      if (forceLocal)

      {

        if (_localPortal == null)

          _localPortal = new DataPortalClient.LocalProxy();

        return _localPortal;

      }

      else

      {

        if (_portal == null)

        {

          string proxyTypeName = ApplicationContext.DataPortalProxy;

          if (proxyTypeName == "Local")

            _portal = new DataPortalClient.LocalProxy();

          else

          {

            string typeName =

              proxyTypeName.Substring(0, proxyTypeName.IndexOf(",")).Trim();

            string assemblyName =

              proxyTypeName.Substring(proxyTypeName.IndexOf(",") + 1).Trim();

            _portal = (DataPortalClient.IDataPortalProxy)

              Activator.CreateInstance(assemblyName, typeName).Unwrap();

          }

        }

        return _portal;

      }

    }

这使得分布式开发和2层开发没什么两样（其实还是有区别的，不过，整套框架已经帮你考虑了哪些代码运行在应用服务层，哪些运行在客户端，你只要把相应的代码写在相应的过程里就可以了，而心里对此对此应该清清楚楚），至于分布式部署的问题，只要在部署的时候，做些配置就可以了。

也就是说，CSLA在物理分层上实现了松耦合，实现了真正的透明。其内部的数据门户接口，适用于任何的通讯协议上，新增通讯协议，仅需在CSLA中按照规则插入对应的适配类即可，与业务系统代码开发无关。

这样处理，有两点好处，第一，现有基于CSLS开发的应用系统可以应对将来新出现的调用协议，代码几乎不用修改，只要跟着CSLA升级重新编译下就可以了；第二，开发当中调试很方便，只要在配置文件中申明"CslaDataPortalProxy"值是"Local"，你就可以在一个调试器里同时调试客户端和应用服务端的代码。

分布式架构和单纯的CS架构本质区别是：利用中间层，将胖客户端或者胖数据库（一般是不可扩展的，遇到性能瓶颈而无法优化时，只能加CPU、内存或者升级机器）上的负载进行合理的分担；数据库的sessin得到了合理利用以响应更多的客户端；中间层应用服务器的可扩展性，可以应对不断增加的业务应用，以提高业务处理能力。

移动对象，是鉴于业务对象在物理分层上是分布在客户端和应用服务端的前提考虑的，移动的是对象的数据，对象的过程各自运行在各自的物理空间里。

CSLA对于开发者，屏蔽的是通讯协议的处理，是对物理分层的松耦合处理。

任何框架都是有缺陷的，比如他的移动对象，每次提交的时候，必须将全部的对象list传递到应用服务器端，如果是大批量对象中仅更新1、2个对象的话，如此移动，显然不合理。但这些都可以在应用系统设计当中规避掉，或者自己重新封装CSLA，进行二次开发，以实现自己的需求，这真是我正在做的工作，

可能上面写的不一定清楚，希望继续交流，有不对的地方请指正。