两个建议

[KimHu01]

我一共有两个建议：
1.在rpc的部分，阿里提出DO，DTO，BO，VO的概念，在过去的两年左右的时间，个人认为，这些概念的提出有助于数据作用域控制，变更控制，也有很好的解耦性，个人认为这种划分是十分必要的，但是目前而言，这些对象之间的转换很成问题，借助第三方工具（很多事基于注解或者xml实现，个人认为不够好，有代码侵入性），或者就是自己通过反射实现对象间转换(我个人也实现了一个逻辑，放在了这些对象的顶级抽象类里面)，因为不想借助注解或者xml文件，所以像我这样子的实现就是要求源对象和目标对象的属性名称必须一致(个人认为不借助注解和xml文件的情况下，这是必要的妥协)，但关键问题在于，属性类型之间的转换，比如timestamp转换成string，这样就要在增加逻辑的复杂性。我个人目前还没有想到很好的办法来实现。所以希望dubbo框架能直接集成一个util类，或者提供一个AbstractPO，在里面实现对象转换工作。或者目前阿里已经有别的优雅的解决办法的话，希望能分享一下~~
2.当采用dubbo分布式之后，众多服务间的依赖关系变得复杂，这个时候，作为开发者，假如修了其中一个服务的话，那么想要本地自测，变得困难重重，我目前了解到的办法就是：
一. 本地启动所有依赖服务，不得不说这是一种很sb的方式。
二. 将所依赖服务暂时打包成jar，引入本服务启动，这种方式个人认为增加了配置的复杂度，不够优雅，也不够好。
三. 就是搭建一套标准环境，自己研发一个系统，该系统也部署在标准环境上，然后开发者只需要启动本地所修改的服务，假如是服务A，通过自研系统(web页面操作)就能将本地服务A "告知" 标准环境，这样在开发者本机访问的时候，当服务A被调用的时候，标准环境会直接调用开发者本机上的服务A，而屏蔽掉标准环境上的服务A(不知道我这么说够不够清楚)。个人认为，dubbo可以不面向restful(我个人认为面向restful也不见得就比dubbo目前这种方式能好到哪儿去)，但是集成进去一个类似第三种方式的解决方案非常必要。

由于我个人对上述两个问题没有找到非常满意的解决办法，所以在此提出建议，如果那位大神已经有了优雅的解决办法，烦请告知，不胜感激~~~ kimhu126@126.com

[lovepoem]

Hi, Welcome!

Would you please consider ask in English? Since this project is moved to ASF repo, we hope it is understandable by people all over the world so that everyone can join to discuss.

Also, please try to ask by sending an email to dev@dubbo.incubator.apache.org-->Subscribe guide , issues is used to track bugs.

[kimmking]

1. you can create a PojoUtils(Actually dubbo has a simple one) project, and then improve it better and better by practice exprience.
2. mock

[libbylg]

@KimHu01 How about servicecomb? It is base on swagger. And there are some tools to mock the dependency service easily, if you have the open-api desctiptions.

[takeseem]

dubbo让我们基本感觉不到rpc的存在：）

如果是一个工程中开发，引入各种XO实际完全没必要，同样通常情况下dubbo也无需定义各种XO，增加开发和运维复杂度。

建议：无非必要不要引入各种XO，通常我们只关注业务模型即可。

[diecui1202]

Will close it. Feel free to reopen if necessary.