|
锁定老帖子 主题：关于应用层次设计的讨论
精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-11
zhongmin2012 写道 我们目前使用的第二种方式的涉及，项目一直沿用，确实使用起来很爽，而且封装了service，service封装了dao，这样访问service就能直接访dao了，而且service都抽到了baseservice，使用spring管理
Ｓｅｒｖｉｃｅ是干啥的？ |
| 返回顶楼 | |
|
发表时间：2012-04-11
ericchi 写道 结构2中，抽象业务逻辑类依赖于IDAO的实现，所有的业务逻辑类都继承了抽象业务逻辑类。
我个人认为： 该结构的优点是简化开发过程，不用针对每一个业务逻辑创建独立的DAO实现，仅此而已。 它的缺点是： 1、SQL语句或HQL语句，将出现在具体的业务逻辑类中。造成了业务逻辑类的臃肿。 2、不利于复用DAO层逻辑。 3、不灵活。举个例子，BusAManager和BusBManager都通过IDAO实现访问关系数据库，某一天由于业务需要，BusAManager依然访问关系数据库，而BusBManager需要访问文件数据库。这个时候要扩展起来，就很麻烦。 结构2，怎么会有SQL出现在业务逻辑类中呢？可能是你理解错了，SQL只能放到它引用的DAO中。 关于这个问题，建议去看看《企业应用架构模式》这本书。我的理解是这两个结构是典型的mvc模式中去掉V，而简化的。我们现在也是用这种模式，web作为一个单独的应用，业务逻辑防止app层，通过hession来通信。对于app层，只有service层和dao层了 我觉得这两种结构都不合理： 1结构会导致过多的interface； 2结构会导致一个类中有过多的方法。 我觉得应该结合这2个结构，原则是把业务相关的逻辑一组放在同一个接口中。其实不要生搬硬套，理解其原理即可，我在实际中会把设计映射到现实模型中，比如现实中有很多业务对象，我就有多少个类，并且通过这些业务对象来协作某个大的事务，那么将这个事务作为某个interface的方法对外公布。 |
| 返回顶楼 | |
|
发表时间：2012-04-11
jiuyuehe 写道 1做点小应用，结构层次鲜明。容易维护修改。
也就是说，性能、吞吐量、可扩展、可维护、可伸缩、安全等一系列的非功能性需求。 对于结构1来说，每个service的Dao都是独立的。在结构上，它可扩展和可维护性会比结构2的强。 因此，大型项目更适合于选择结构1。 结构2，层次划分不清晰，耦合度比较高。一旦涉及到变化，他的抽象模式就要被打破，必然也带来了一系列的不可预估的麻烦。 我想说，关于可扩展、可维护这两点，在应用架构分层上只起到非常小的效果，要想得到更大的效果需充分应用OOD\OOA对业务模型的建模。 仅仅要求开发人员定义几个service和dao是做不到的可扩展和可维护的，我们项目组的开发人员也是会用service和dao，完全跟OO设计不搭边，维护和扩展真痛苦。 |
| 返回顶楼 | |
|
发表时间：2012-04-11
devroller2 写道 ericchi 写道 结构2中，抽象业务逻辑类依赖于IDAO的实现，所有的业务逻辑类都继承了抽象业务逻辑类。
我个人认为： 该结构的优点是简化开发过程，不用针对每一个业务逻辑创建独立的DAO实现，仅此而已。 它的缺点是： 1、SQL语句或HQL语句，将出现在具体的业务逻辑类中。造成了业务逻辑类的臃肿。 2、不利于复用DAO层逻辑。 3、不灵活。举个例子，BusAManager和BusBManager都通过IDAO实现访问关系数据库，某一天由于业务需要，BusAManager依然访问关系数据库，而BusBManager需要访问文件数据库。这个时候要扩展起来，就很麻烦。 结构2，怎么会有SQL出现在业务逻辑类中呢？可能是你理解错了，SQL只能放到它引用的DAO中。 关于这个问题，建议去看看《企业应用架构模式》这本书。我的理解是这两个结构是典型的mvc模式中去掉V，而简化的。我们现在也是用这种模式，web作为一个单独的应用，业务逻辑防止app层，通过hession来通信。对于app层，只有service层和dao层了 我觉得这两种结构都不合理： 1结构会导致过多的interface； 2结构会导致一个类中有过多的方法。 我觉得应该结合这2个结构，原则是把业务相关的逻辑一组放在同一个接口中。其实不要生搬硬套，理解其原理即可，我在实际中会把设计映射到现实模型中，比如现实中有很多业务对象，我就有多少个类，并且通过这些业务对象来协作某个大的事务，那么将这个事务作为某个interface的方法对外公布。 您好， 在业务逻辑层确实会出现SQL，因为AbstractBaseService依赖于IDao的实现，而BaseDao作为IDao的实现，只提供了通用的增删改查方法。 因此，业务逻辑层实现具体的业务操作时，必须传入业务对应的SQL。 另，对于Dao层而言，一个Dao层对应一个实体表（关系数据库或FDS库）的操作是必要的。因为，在大型项目中，随着业务增长，你的存储方式可能会产生变化，因此改变对应的某一个DAO就能够适应这样的变化。 再，我赞成您的另一个观点：把设计映射到现实模型中。 您现在所用的模式。web容器是独立的，app作为单独的应用，独立的提供服务。这样的思想有点服务化的意思。但我不建议将全部的app层都服务化。服务化的前提是这个服务的可复用度有多重，否则会增加额外的通讯开销，而无实际用处。另，服务化的粒度划分也比较重要。在SOA思想中，提倡组件化，一个组件就是一个服务，外部不知道组件内部的实现，只了解接口，保持知识最小化原则。我想也是这样的意思。 谢谢您推荐的图书！ |
| 返回顶楼 | |
|
发表时间：2012-04-11
ericchi 写道 jiuyuehe 写道 1做点小应用，结构层次鲜明。容易维护修改。
也就是说，性能、吞吐量、可扩展、可维护、可伸缩、安全等一系列的非功能性需求。 对于结构1来说，每个service的Dao都是独立的。在结构上，它可扩展和可维护性会比结构2的强。 因此，大型项目更适合于选择结构1。 结构2，层次划分不清晰，耦合度比较高。一旦涉及到变化，他的抽象模式就要被打破，必然也带来了一系列的不可预估的麻烦。 我想说，关于可扩展、可维护这两点，在应用架构分层上只起到非常小的效果，要想得到更大的效果需充分应用OOD\OOA对业务模型的建模。 仅仅要求开发人员定义几个service和dao是做不到的可扩展和可维护的，我们项目组的开发人员也是会用service和dao，完全跟OO设计不搭边，维护和扩展真痛苦。 赞同业务建模，非常必要。 架构设计也是根据业务建模以及对应标准产生的。 产品架构也是在发展过程中，不断完善的。 |
| 返回顶楼 | |
|
发表时间：2012-04-11
第二种方法好，第一种分层n多DAO，啰嗦折腾，完全没有必要，我采用的是第二种分层。
|
| 返回顶楼 | |
|
发表时间：2012-04-11
第二种就是一个baseservice和一个basedao来进行通用的增删改查，其他和第一种没什么区别，而且在我看来两种都没什么本质区别。求讲解。
|
| 返回顶楼 | |
|
发表时间：2012-04-11
JackyCheng2007 写道 大家都没有考虑过不用DAO，直接用service。spring和hibernate的合作使得很多service里面直接调用DAO的方法，很是麻烦。
目前我就是这么搞的,还没发现啥不方便的地方!!! |
| 返回顶楼 | |
|
发表时间：2012-04-11
ltian 写道 zhongmin2012 写道 我们目前使用的第二种方式的涉及，项目一直沿用，确实使用起来很爽，而且封装了service，service封装了dao，这样访问service就能直接访dao了，而且service都抽到了baseservice，使用spring管理
Ｓｅｒｖｉｃｅ是干啥的？ 业务逻辑层，说得急了点，可能说的不清楚，呵呵 |
| 返回顶楼 | |
|
发表时间：2012-04-11
神马分层、神马层次。
我就想到了机构臃肿的国.企政.府。 这大概就是技术中毒吧，个人认为相当多的情况下本来不需要那么多的分层的。但是一代代的后继者都追随着这种技术。项目中一个Dao层几十上百个类，一个Service层几十上百个类，大多数情况那些类都是空的，仅仅是为了将来可能出现的代码变动。再联想到Struts2那臃肿的配置，Hibernate那臃肿的配置。。。不知所云了，大家忽视我吧 |
| 返回顶楼 | |
