关于Duwamish中的Facade.请各位来指教。

是说业务外观是由业务规则composite而成的？
那么数据验证部分我要做在业务规则层？

解决方案 »

  1.   

    刚才是以为是Web可以绕过BF直接用BR层。
    再看一遍Duwamish的vsd，觉得应该是BF可以绕过BR直接用DA层。
    有些清晰了。
      

  2.   

    外观层只是能业务层的一个概括,web层可以访问外观层,也可以访问业务层.
    外观层是由业务层来实现的,但是业务层的东西不定都要出现在外观层
    数据验证两层都有的,公共的应该放在业务层
      

  3.   

    怎么也学不像。为什么我的外观中的方法和业务规则中的方法差不多？
    ----------------------------------------------------------------
    我用外观模式时，web调用facade中的方法，但facade中不写业务的实现，facade的方法调用BR层的方法，而BR层的这个方法可能包含很多规则，由多个private方法组成。web做数据验证，个人觉得的在界面层用javascript去控制是最好的。可以写一些.js文件，在页面中包含进去。建议BF不直接访问DA层，其实外观模式和其它一些adapte模式，策略模式..等等，形式都是类似的，把外观模式和其它模式结合起来，或者变成其它模式，很简便。基于这点，BF就更不能直接去访问DA层了。
      

  4.   

    不同意 zjsen 说的：“外观层只是能业务层的一个概括,web层可以访问外观层,也可以访问业务层.”
    如果用了外观模式把一组相关业务封装起来，web层还可以访问业务层，要facade层简直没有什么意义。没有使用外观模式的，web层当然可直接访问业务层了。
      

  5.   

    facade层简直没有什么意义
    -----------------------
    外观层的意义在于简化接口,概括流程.外观只是业务层的一个补充.通常情况下外观层不会业务层封装起来(这点duwamish就是例子,它只对几个重要且复杂的操作实现外观层).很多时候web层需要灵活控制业务流程,需要直接调用业务层.web做数据验证，个人觉得的在界面层用javascript去控制是最好的。可以写一些.js文件，在页面中包含进去。
    -----------------------
    数据验证不是仅仅做些数据格式的合法性判断的,很多情况光是脚本是无法检验的.这种方式只能做为补充,用来增强界面友好而已,是无法代替业务层的数据验证的.另外,用脚本验证的数据是不可信的,因为ie端完全可以禁用脚本或者改客户端的脚本来达到输入非法数据的目的
      

  6.   

    TO zjsen,你的意思是Web层可以访问BF也可以访问BR?
    但是我看Duwamish的UML图里画的Web层只访问BF,而BF访问BR和DA.数据验证如果两层都有，那么如何分工？
      

  7.   

    正在研究Duwamish
    学习！！