|
锁定老帖子 主题：关于应用层次设计的讨论
精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-13
ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ |
| 返回顶楼 | |
|
发表时间：2012-04-13
crud0906 写道 ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ 目前，我们的项目用的是结构2.但是我并不认为结构2是一个好的结构。 所以希望系统能够逐步的向结构1的方向调整和重构。 结构2，首先是sql和业务层耦合太高，降低了复用度；其次，对于维护和扩展也并不好。 所以，我把这个例子拿出来跟大家一起讨论。 我认为DAO层应该作为独立的一层，且每一个实体对应一个DAO。 DAO上层，应该是细粒度的服务层，提供一些细粒度的业务逻辑。 再上层是应用层，应用层提供一些具体的业务，可能几个细粒度的业务层，组织成一个应用层。 应用层之间可以相互调用，但两个应用层，不能够互相调用对方的细粒度业务层。 我个人认为，这样的层次才比较符合设计的一些原则。 |
| 返回顶楼 | |
|
发表时间：2012-04-13
ericchi 写道 crud0906 写道 ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ 目前，我们的项目用的是结构2.但是我并不认为结构2是一个好的结构。 所以希望系统能够逐步的向结构1的方向调整和重构。 结构2，首先是sql和业务层耦合太高，降低了复用度；其次，对于维护和扩展也并不好。 所以，我把这个例子拿出来跟大家一起讨论。 我认为DAO层应该作为独立的一层，且每一个实体对应一个DAO。 DAO上层，应该是细粒度的服务层，提供一些细粒度的业务逻辑。 再上层是应用层，应用层提供一些具体的业务，可能几个细粒度的业务层，组织成一个应用层。 应用层之间可以相互调用，但两个应用层，不能够互相调用对方的细粒度业务层。 我个人认为，这样的层次才比较符合设计的一些原则。 DAO应该是很轻的一层，主要是为了业务逻辑和db解耦。所以这层最好只考虑持久层的逻辑，不到不得已千万不要用存储过程实现业务逻辑。 |
| 返回顶楼 | |
|
发表时间：2012-04-13
devroller2 写道 ericchi 写道 crud0906 写道 ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ 目前，我们的项目用的是结构2.但是我并不认为结构2是一个好的结构。 所以希望系统能够逐步的向结构1的方向调整和重构。 结构2，首先是sql和业务层耦合太高，降低了复用度；其次，对于维护和扩展也并不好。 所以，我把这个例子拿出来跟大家一起讨论。 我认为DAO层应该作为独立的一层，且每一个实体对应一个DAO。 DAO上层，应该是细粒度的服务层，提供一些细粒度的业务逻辑。 再上层是应用层，应用层提供一些具体的业务，可能几个细粒度的业务层，组织成一个应用层。 应用层之间可以相互调用，但两个应用层，不能够互相调用对方的细粒度业务层。 我个人认为，这样的层次才比较符合设计的一些原则。 DAO应该是很轻的一层，主要是为了业务逻辑和db解耦。所以这层最好只考虑持久层的逻辑，不到不得已千万不要用存储过程实现业务逻辑。 赞同，DAO层只关注持久化的实现，不要渗入业务逻辑。 |
| 返回顶楼 | |
|
发表时间：2012-04-13
cseu 写道 本人以为：
第一种适用于业务逻辑复杂的中大型项目，这样的项目特定于领域对象的DAO操作更多。这种方式层次清晰，低耦合，代码重用性更高。副作用是某些领域对象的业务逻辑层会非常薄，只是简单的调用DAO。 第二种适用于业务逻辑简单，绝大部分都是简单的CRUD的小型项目，简单的CRUD都可以使用泛型的BaseDAO完成，减少了“不必要”的薄业务逻辑的胶合代码。但这种方式耦合度高，正因为如此更适合几乎是CRUD的小型项目 PS：很久没看到这么接地气的帖子 我觉得这个兄弟，说的很有道理 第二种只能做业务逻辑非常简单的应用。否则一些复杂的查询必须要写在service里才能实现 如果是第二种，其实那个abstract service没有存在的必要的，service直接实现idao就ok了 |
| 返回顶楼 | |
|
发表时间：2012-04-13
ericchi 写道 devroller2 写道 ericchi 写道 crud0906 写道 ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ 目前，我们的项目用的是结构2.但是我并不认为结构2是一个好的结构。 所以希望系统能够逐步的向结构1的方向调整和重构。 结构2，首先是sql和业务层耦合太高，降低了复用度；其次，对于维护和扩展也并不好。 所以，我把这个例子拿出来跟大家一起讨论。 我认为DAO层应该作为独立的一层，且每一个实体对应一个DAO。 DAO上层，应该是细粒度的服务层，提供一些细粒度的业务逻辑。 再上层是应用层，应用层提供一些具体的业务，可能几个细粒度的业务层，组织成一个应用层。 应用层之间可以相互调用，但两个应用层，不能够互相调用对方的细粒度业务层。 我个人认为，这样的层次才比较符合设计的一些原则。 DAO应该是很轻的一层，主要是为了业务逻辑和db解耦。所以这层最好只考虑持久层的逻辑，不到不得已千万不要用存储过程实现业务逻辑。 赞同，DAO层只关注持久化的实现，不要渗入业务逻辑。 实际使用中，dao很难没有业务逻辑的因素在里面，特别是针对一些复杂的查询 |
| 返回顶楼 | |
|
发表时间：2012-04-13
waveheart 写道 ericchi 写道 devroller2 写道 ericchi 写道 crud0906 写道 ericchi 写道 crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 sql复用怎么办呢？楼主的项目是这个模式吗？ 目前，我们的项目用的是结构2.但是我并不认为结构2是一个好的结构。 所以希望系统能够逐步的向结构1的方向调整和重构。 结构2，首先是sql和业务层耦合太高，降低了复用度；其次，对于维护和扩展也并不好。 所以，我把这个例子拿出来跟大家一起讨论。 我认为DAO层应该作为独立的一层，且每一个实体对应一个DAO。 DAO上层，应该是细粒度的服务层，提供一些细粒度的业务逻辑。 再上层是应用层，应用层提供一些具体的业务，可能几个细粒度的业务层，组织成一个应用层。 应用层之间可以相互调用，但两个应用层，不能够互相调用对方的细粒度业务层。 我个人认为，这样的层次才比较符合设计的一些原则。 DAO应该是很轻的一层，主要是为了业务逻辑和db解耦。所以这层最好只考虑持久层的逻辑，不到不得已千万不要用存储过程实现业务逻辑。 赞同，DAO层只关注持久化的实现，不要渗入业务逻辑。 实际使用中，dao很难没有业务逻辑的因素在里面，特别是针对一些复杂的查询 嗯，所以说dao的独立是必要的，可以保证每个DAO具有独立的可操作性。 |
| 返回顶楼 | |
|
发表时间：2012-04-14
不知道lz的sv层依赖于dao层是怎么封装的，所以不敢确定用哪个设计比较好
|
| 返回顶楼 | |
