[思考] 如何区分业务层和应用层
 |
zhutao65786591
2010-08-04
在讨论spring版本升级时，大家比较关注的是spring事务管理。咋们的事务主要集中在service层，service层中的服务有些支持事务有些不支持事务。这一特性，使boss系统不能很好的使用spring的Aop特性。
经过demo尝试，未发现有效的解决方案，和光瑞讨论，光瑞提出咋们系统现在主要存在一个问题，就是业务层和应用层耦合在一起，没有有效的分离。（在应用层添加事务拦截，不进行事务处理的地方直接调用业务层对象） 因此现在的问题时，业务层和应用层的边界是什么，怎么分离业务层和应用层？ spring3.0对事务的处理，我想到的几种方案如下： 1、在新版本中，不使用spring新特性中的事务处理，先明确业务层和应用层的边界，以后设计时，分清业务层和应用层，spring新特性只处理以后的事务管理，渐渐从之前的service层分离出业务层和应用层。 2、尝试单独写一个拦截器，进行事务的统一管理；（拦截器的规则是怎样？如何才能区分service什么时候呆事务，什么时候不带事务） 3、通过在service中添加属性或参数等方式，判断service是否支持事务。 |
 |
sharajava
2010-08-04
我们当然不是为了应用某种技术新特性而用，核心架构划分才是最核心的。
|
|
sharajava
2010-08-04
个人认为：
所谓业务层应该是领域层的含义，企业应用核心所在；而应用层实际上是服务的门面，应该是比较薄的一层。应用层的工作实际上是通过对领域层的调度，来实现应用（接入）的接口，应用层可以理解成给系统外部（包括客户端，外部系统等）提供服务的（也可以叫服务层）。 如果我们能按理想划分开应用（服务）层和业务（领域）层，那么我们就是可以基于这样的规则来配置事务： 应用（服务）层需要事务； 业务（领域）层不需要事务。 很清晰，很明确。 |
|
zhhui_syist
2010-08-04
在我们现有的系统要想完全将服务层区和业务层区分开来有点难度，而且目前只有业务受理模块才使用了领域逻辑，而其他模块的业务逻辑基本上都是采用服务的形式提供的。
所以采用你所说的第一种方法我认为会是一项工作量比较大的工程。但是这也是最佳的一种选择。 |
|
sharajava
2010-08-06
实际上我们这个讨论的本质是企业应用架构的设计问题，层次的划分，业务逻辑的组织。
建议大家有时间都把经典的《企业应用架构模式》读至少一遍，这样我们可能会扫清很多不必要的沟通障碍。 |
