浏览 3207 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-04-24
传统的J2EE系统的分层,一般是WEB展示层、Web控制层、业务逻辑层、数据访问层。 各层的职责比较简单,控制层仅处理Web参数与数据并传递给业务逻辑层。而具体的业务逻辑放在Service层即业务逻辑层中。同时,事务的控制边界也在这一层。Dao层对数据库的操作,更简单的理解为对SQL的拼装。 上面的各层泛泛来讲,都容易理解。具体用法上,又会有一些延伸。比如说Dao层,有的由一组Dao类来实现,有的则只有统一的Dao。这里的Dao类似一个工具类。比如使用ibatis2的时候,Dao可能只是一个Client及对应的xml。
问题: 在具体实施后,存在一些问题。往往一开始开发的时候,需求比较简单,各表都只需要增删改查。所以,往往类的创建往往是数据库导向的。即一张表对应一个Dao类/接口,进而又对应一个Service类/接口。 随着开发的继续,需求的补充,一些主业务表的Service往往贯穿整个业务系统的流程。自然而然,业务逻辑的代码开始膨胀。结果是主业务表的Service类异常的庞大。
因为领域模型是一个充血的模型,而目前传统的分层属于贫血的模型,转换差别比较大。如果是在原有的贫血模型基础上,再加入Facade层。 可是Facade层跟Service层到底有什么差别呢?如果没有严格的规则的话,最后只会导致Facade层是一个空壳。 是否有其他的解决方案呢?
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-04-26
facade层确实是有可能成为一个空壳,还是期待有人指点。
|
|
返回顶楼 | |