关于分层原则疑惑——Facade层与Service层的划分标准？

 

 

传统的J2EE系统的分层，一般是WEB展示层、Web控制层、业务逻辑层、数据访问层。

各层的职责比较简单，控制层仅处理Web参数与数据并传递给业务逻辑层。而具体的业务逻辑放在Service层即业务逻辑层中。同时，事务的控制边界也在这一层。Dao层对数据库的操作，更简单的理解为对SQL的拼装。

上面的各层泛泛来讲，都容易理解。具体用法上，又会有一些延伸。比如说Dao层，有的由一组Dao类来实现，有的则只有统一的Dao。这里的Dao类似一个工具类。比如使用ibatis2的时候，Dao可能只是一个Client及对应的xml。

 

问题:

在具体实施后，存在一些问题。往往一开始开发的时候，需求比较简单，各表都只需要增删改查。所以，往往类的创建往往是数据库导向的。即一张表对应一个Dao类/接口，进而又对应一个Service类/接口。

随着开发的继续，需求的补充，一些主业务表的Service往往贯穿整个业务系统的流程。自然而然，业务逻辑的代码开始膨胀。结果是主业务表的Service类异常的庞大。

 

 

因为领域模型是一个充血的模型，而目前传统的分层属于贫血的模型，转换差别比较大。如果是在原有的贫血模型基础上，再加入Facade层。

可是Facade层跟Service层到底有什么差别呢？如果没有严格的规则的话，最后只会导致Facade层是一个空壳。

是否有其他的解决方案呢？

 

 

 

 

facade层确实是有可能成为一个空壳，还是期待有人指点。