很稀奇么？

@hhjswf 这看你业务来着。我自己预想的是订单这个整体是一个服务

@linglin0924 #89

我认为是因为 lz 习惯了 bookinfo 一股脑带出来可以直接渲染，页面不用太多异步逻辑，加上以前单服务的时候是可以 join 起来也方便，所以直接返回也没什么问题。这是 ok 的，因为那时候大家都这么做的。

但是到现在新微服务架构后，两个服务分开了，分别提供了 curd ，就没必要再加一个聚合的 bookinfo 接口，因为确实没必要。

这个构架不用考虑握手太多的问题。人少对系统没压力，人多接口分细了反而能降低系统负载，前端也可以用中间件做 ttl 缓存。问题很好解决，或者说压根不是问题。

时代变了呀~

@wupher 他这个已经是微服务架构了。不同业务直接不要直接操作，更何况在不在同一个库都不一定

@wunonglin #41

网站人流量多的可以在前端用用中间件做 ttl 缓存，网站人流量少的你也不用考虑多次请求带来的负载。

每个模块都有 curd 了，那就没必要再给你搞一个聚合接口，你说可不可以，当然可以，只是没必要而已。

两者都合理，具体还是看业务场景。

但第二种明显更好，毕竟你是获取 bookinfo ，其他东西没必要带给你，你再根据 bookinfo 里面的外键 id 去其他对应的接口查询即可。

这样的话再根据各个客户端的需求，去做就好了。比如页面需要一次性显示，app 不需要，那这样接口拆分的就很合理

再者就是可以“渐进式显示”，打开 bookinfo 页面，先显示 bookinfo ，然后再去请求 order ，这样用户就能先看到页面，不至于要等全部数据出来才显示。

比较复杂的例子：一个 bookinfo 里面，可能有 tags 、orders 、images 、comments ，如果全部给你，数据多的话体验会很差。那我可以先显示 bookinfo ，然后再根据用户点击的 tab ，再去加载对应的数据（懒加载）那体验会好很多，这样系统负载也会小很多，毕竟可能有的用户只是想某几个模块而已

人家把你当傻子，结果你真以为是概率问题？就算这问题过了，还会有下一个破下线的，认真你就输了

放~

这个是展示端的功能，和数据库有毛线关系

又丑，又垃圾，本身就是作为屏下摄像头的一个过渡方案，占空间

ng 和 vue 是两个世界，学好 ng 再看 vue 和 react 就会发现如鱼得水

ng+1

同 ng 开发+1 。

A：传进来的是那个结构体的内存地址（吧？）
B：通俗来说传入的 a 是 new 了一个一个零值的结构体，然后在把你传的结构赋值上去。

路走错了。你这功能这么设计本身就有问题