web层直接调用 dubbo的服务，合适吗？

Question

@dubbo 你好，想跟你请教个问题：

正在开始做一个新的分布式项目，打算使用dubbo来做服务。但是在实施的时候就遇到了一个问题。

我们的项目结构，简单来说，就是spring rest controller 调用 dubbo service, dubbo service调用DAO（hibernate进行数据映射，进行数据的操作）。

首先想请教一下，这样的设计是否合理？跟其他人聊了一下 ，好像大家通常会把dubbo放在更后端一点，比如日志处理，后端统计，服务的异步解耦。像我们这样，直接在web层对dubbo的service进行调用，或者在dubbo的service里面对hibernate进行调用，是否合理？

现在我们这样做的问题是，当需要加载关联对象的时候（A关联B），dubbo service返回的数据，必须是包含完整的数据，如果只返回A，不可能再在controller里面 进行a.getB()的调用。现在担心如果全部数据返回（或者再构建一个bean，只返回controller需要的部分对象属性），影响效率和性能。
所以现在的数据的模型，不带任何复杂对象的关联，全是基本数据类型。不过这样的话，更让我感觉很别扭。这样的模型不仅是贫血的模型而且连面向对象的设计都算不上了。

不知道我把我的问题描述清楚没有。希望各位高手能给点建议。谢谢！

Answer 1

楼上的，还少了一个 dubbo.server 服务提供者网站;

Answer 2

各位好

我这里遇到一个问题，spring模块是这样的

dubbo.basic 公共类库;
dubbo.model 定义 pojo
dubbo.provider 里面包含 接口dao及实现,  service接口的实现
dubbo.service 定义的接口模块;
dubbo.web 项目web模块;

service ,dao接口及实现的 基础代码;
BaseService, BaseServiceImpl, BaseDao , BaseDaoImpl 
每个相关业务类都继承他们;

采用 dubbo+zookeeper (spring+springmvc+hibernate)

server 服务提供模块 spring配置大概是
component-scan:  service 以及 provider

aop pointcut 到 service 模块下的根包;

==========================================
web controllerj

@Autowired
private XxxService xxxService;

由于支持 hibernate session 赖加载;

当使用 xxxService.load(id); //BaseService 下的接口，这样使用会出现  no session的错误，

但是如果是下面的用法就没事;

如 XxxService 下的有个接口是  getMessage(id);
则 XxxServiceImpl 这是接口实现类里
public Xxxx(Pojo类) getMessage(id) {
    Xxxx xxxx=this.load(id);
    return xxxx;
} //这样用就没有问题，很奇怪;

而且当对一个实体进行 save操作后，成功时，也是取不到 getId() 值;  (我在 server 下直接实验操是可以获取到 id 值的)

===============================================

我是这应该是 web模块 是一个 web项目, server 也是一个web项目, 采用 rpc 这种远程调用，可能session 会发生变化，或关闭;

但是如果 使用 xxxService.get(id)；//这是没有问题的;

Answer 3

教程目录：
http://tieba.baidu.com/p/4050410942

Answer 4

请问，楼主，你是怎么用dubbo的，怎么分布式部署provider的

Answer 5

类ejb调用

Answer 6

感谢你的回复。在以前的公司，业务的东西都是放到service层，所以最初我也是打算在service调用dubbo service，只是现在的同事不习惯用太多层次。推行起来有点麻烦

Answer 7

我觉得要看情况，如果duboo后台Service已经封装得不错，那么是可以在Web层直接调用的。如果封装不好，或者一个业务需要多个Duboo Service协作完成，建议从Service层调用Duboo Service。

Answer 8

兄弟，你好，在你们的web 层应该调用service层，在service层才调用dubbo的service是比较合理的，因为在service层可能会调用多个dubbo service，这些都属于业务逻辑代码，在这里可以进行单元测试，如果你在web层，单元测试实现比较困难，结构的划分也比较混乱

Answer 9

你好，你的问题，应该是2个方面

1、是否在spring mvc的controller中调用dubbo的service？

     如果是从springmvc 的controller调用service，在service中调用dubbo，存在的一个好处是，可以单元测试，并且比较容易，如果不需要在service中单元测试，可以直接在controller中调用dubbo的service

2、返回数据，是简单类型还是复杂类型？

   如果返回复杂类型，这样导致的问题是这些服务的重用新不好，失去了soa 最重要的服务重用原则，所以，我建议返回简单类型，在springmvc的controller中调用多个soa的方法实现页面的需要