学习了外观模式:认识到作为一个客户程序不要直接跟子系统的实现部分耦合在一起.
我现在的系统的开发模式如果下面:
       访问              访问                          操作
界面层--------->业务层----------------->数据库访问层------------>数据库
目前界面层跟访问层我觉得的耦合性很强,具体如下:
假如采购单有两张表(PO(采购基本信息),PODtl(采购商品表)),在数据库有这两张表,在业务层就为这两张表建了两个业务类PO,PODtl.在界面层就直接调用了这两个业务类(PO,PODtl).这样确实耦合性是强了点.
于是我想对系统进行一个分层的重构,结构如下:
    ---------------------
   |                     |
界面层---->控制层----->外观层------>业务层------>数据库访问层----->数据库
界面层和控制层是放在同一个工程里面,控制层是的功能主要是把界面层的一些控制功能分离出来,界面层和控制层可以同时调用外观层.外观层是主要功能是封装业务层
的接口,例如采购订单的两个业务类(PO,PODtl),如果增加了外观层,就是增加一个类(POFacade)来封装这两个业务的公共方法.使用界面层或控制层直接跟外观层打交道
大家对我这个想法的看法怎么样,请指点,或者有没有更好的分层方法,谢谢!!

解决方案 »

  1.   

    我来说说吧首先不知道你说CS还是BS,如果是BS的话,估计你说的都不成立了,所以我猜你是CS首先你那个有点像MVC的结构,现在流行MVC+hibernate(数据库层)第一,你对界面层有错误解,其实界面层已经封装好,在designer.cs的页面里面,你看看解决方案资源管理器,那里是对界面(UI)的封装,那里其实已经是一层了第二,你说所的控制层,应该说的是事件的触发吧,在designer.cs里面其实已经封装好,也不用再你搞了,换句话说,你所说的界面层与控制层VS2005已经帮你做了,只是你不知道而已
    (第一、二点是MVC中的V)第三,你说外观层与业务层,我这里搞不懂,如果是我设计的话,就会把事件触发的那个{}里面的事作业务流程处理,主要是从一些数据库里面或者一些其它的封装好的类里面拿一些信息,然后决定交给哪个数据库程序去处理,主要是作判断和流程处理,这里的代码可能有几百行(这里是MVC中的C)第四,有一些封装好的类,这些类应该是与界面与流程无关的,比如说从网上下载文件,从数据库里面拿东西,传个参数进去就好了
    (这里是MVC中的M)最后,你去了解一下什么是hibernate,只能这样子说至于什么是MVC,我觉得不用太在意了,因为每个工程都不同,你觉得哪样做方便就好了
      

  2.   

    可以这样对客户端业务逻辑包装,但不应该叫Facade