我们服务分层时可能会遇到一些问题： 比如在componentA里我们可能会查一下用户信息，同时componentB里可能也需要用到同一个用户信息，这时我们有几种选择： componentA里查一下db或rpc，componentB里再查一下db或rpc。这样的话会带来多次db或rpc查询，浪费了资源，带来性能损失 在componentA和componentB外层查一次db，然后再传给两个component。这样问题是我们每次遇到这种情况都要改代码，把查询不断往上层提，除非提到最上层，否则也不能从根本上解决，而如果全提到最上层的话那分层意义就会弱很多 其中一个component查完自己存起来，然后一层层往下传，哪里用到就通过参数传过去。这样一是会带来参数无限扩张；二是有顺序问题，比如现在是A请求了存起来B用，那就要求A要在B之前调用，如果A前面再来个C也要用，那就需要把A里请求的代码挪过去，很难维护 很多时候，我们的方法常会产生一些逻辑过程的中间值，用于后面其它逻辑使用，这样的话中间值就会在逻辑里各种传递，可能会越传越深，导致如果这个值有什么变动，就需要改很多地方 request
后端服务代码分层是个老话题，但最近几年没什么人聊了，因为吹牛的去聊虚拟化、高可用、k8s，骗钱的去聊ai了。也导致一些新人基础代码没怎么写过，就开始疯狂学习这些高大上的东西，不过我一直觉得，先把基础的搞好了，再提高大上也不迟。而且这些年来我见过了各种分层，但似乎没有哪一种是能够真正解决了高复用，低耦合，又不麻烦的，大部分是都是会偏向于理论化，实际用在项目上总会放人懵逼，这一块代码到底要放哪呢？怎么放更合理呢？以至于每次有新模块时，我都会纠结怎么设计，因为老觉得之前做的还有可改进的地方；经过好多年的思考和迭代，希望能总结出一些东西来 首先，MVC对于当下的服务分层有些太简单了，或者说最早设计出来时就太简单了，只是一个偏指导性的，而且当下前端的解耦，让View层更不变的可有可无，让我感觉更有指导方向的是阿里牵头出过的《java开发手册》，虽然我用过c，php，golang，甚至matlab，C#，js，但唯独没有正经用过java，不过java本身是一个工程向很重，架构方法论发展非常好的语言，哪怕不用java，它也会在设计模式、工程架构上对人有很高的启示和示范 再提问题，为什么要分层？我个人
eLangX
不要瞎写！不要瞎写！不要瞎写！
