惊了 Java 转岗写 PHP 的都喜欢把代码写的这么复杂么

[KomeijiSatori]

一个简单的从数据库里获取指定 APPID 下所有广告的接口，内部封装了一大堆神奇的东西

从数据库里拉取东西先要调用 getAdvertService 获取到获取广告的 Service,然后这个 Service 又要获取 AdvertLogic,然后 AdvertLogic 里又调用 AdvertPosLogic,然后 AdvertPosLogic 里才调用 AdvertPosModel 来连接数据库查询。。

然后我精简成几行代码还被吐槽了。。。

https://i.imgur.com/xi6Z0Fn.jpg

[liprais]

没法维护是不假，性能就是胡扯了

[chinvo]

如果那是领导，赶紧跑路

回头性能出问题怕不是全是你背锅

动态解析语言就要有动态解析语言的样子，又不是 C# JAVA 那种预先把各种层、服务、依赖都热起来的模式，弄这么多层自己找不自在

PHP 目前也就是分个 MVC + Service 就能满足维护性需求了

[yiqiao]

星号。。。要是接口形式的话重要信息不是暴露出去了吗。。

[CDuXZMAPgHp1q9ew]

似乎不建议直接 select *

[KomeijiSatori]

@yiqiao 当然没这么不严谨...这个表里没有敏感数据,表里就存了广告链接和广告 ID,这几个参数都是前端要用的，有敏感数据的查询肯定会做过滤的

[agoodob]

（不黑语言，纯提供案例）之前有个 Ruby on Rails 项目，是 Java 程序员转岗写的，
CSS 响应式不写 media query 写成 javascript 判断屏幕宽度，
然后用 jQuery 来 show() 和 hide()

[agoodob]

这部分代码最后当然全部删掉了。改成正确的响应式写法

[silencefent]

没错吧，laravel 都这么写

[zjsxwc]

虽然我是写 PHP 的，但我觉得没有毛病。

“从数据库里拉取东西先要调用 getAdvertService 获取到获取广告的 Service ”： 通过方法获取 service 比直接通过属性获取好。

从依赖角度看也没有问题：
getAdvertService --依赖--> AdvertLogic --依赖--> AdvertPosLogic --依赖--> AdvertPosModel

[learnshare]

@agoodob 早期没有 media query 这些东西

[newtype0092]

我也觉得写'*'太随便了，现在是可能表里没有敏感数据，可是以后如果表里加了新的字段，所有用'*'的地方你敢不全检查一边？

[fyibmsd]

javaer 写 helloworld 用四种设计模式 了解一下

[fyibmsd]

[The Abuse of Design Patterns in writing a Hello World Program]( https://taskinoor.wordpress.com/2011/09/21/the-abuse-of-design-patterns-in-writing-a-hello-world-program/)

[oovveeaarr]

这个问题就是过度优化啊
不过说句真的，PHP 如果也要封这么多层，每次请求都要 Load 一堆文件，你们 100IOPS 都没有的腾讯云普通云磁盘，真的撑得住么。搞得跟隔壁 Laravel 一样，一个请求就初始化一下几十上百个文件，然后写出来一个只有 5req 的项目，这个性能问题比用不用*大多了吧。
要牢记 PHP 是脚本语言，如果非要像是 Java 那样，我为啥不选择 Java 呢？更别说这两门语言在 Web 下生命周期都完全不一样了，影响性能的点自然也不一样，都说要入乡随俗，这件事不也是这样么？

[gaolycn]

@agoodob 以前不都是 javascript 判断屏幕宽度吗？只能说明那个 Java 程序员不了解 css media，后端转岗的也正常啊

[ranwu]

经验不足，不敢妄下结论。不过从我学习 symfony 框架来看，调用逻辑也和这个差不多，把一个大的模块做成一个 service，然后再从这个 service 里调用相应的逻辑，我觉得这样做更符合框架规则，更有利于维护吧，代码也更清晰。站在公司角度考虑，肯定要在性能和可维护性做一个平衡。

[aa6563679]

后台分 3 层还是很常的模式吧

[xrlin]

那个。。。难道脚本语言就不适用设计模式吗？至少用 Service 处理逻辑还是业内通用的模式吧，不管用什么语言，这样写测试也方便，虽然 Logic 层我一般分开，但是 service 层还是要有的。

[janxin]

我觉得就是*的问题


当然 java 程序员写什么都像 Java 也很正常的

[instein]

java 也可以什么设计模式都不用， 也不分层什么的， 几行代码或一个方法把所有事情都干完， 性能什么的其实都不难， 所以为什么会变成当前这种编程方式， 建议没想过这个问题的思考一下， 应该还是有所受益的。

[instein]

盖高楼和盖小屋的方法， 本来就有所不同

[bromineMai]

@newtype0092
不用*也有这种问题,有个常见场景：给某个方法传一个记录对应的数组 /对象参数，以后加个新业务字段，不用*所有调用的地方你都要改。
接口字段泄露的问题相对来说其实很好处理,平时输出前 array_walk unset 下就好

[Actrace]

@ranwu 其实公司根本不关心这些问题。

[Marfal]

我想吐槽一下字体...

[newtype0092]

@bromineMai 那到也是，不过我还是觉得，在万一疏忽的情况下，少返回一点数据顶多前端显示 bug，算是体验问题，多返回数据可能会导致安全问题，更严重些吧。
而且清清楚楚写明白到底返回了那些字段比一个*看着清晰，别人或者一段时间后的自己来看更方便吧。

[agoodob]

@learnshare 不不不，是 2016 年左右的项目。media query 100%存在

[agoodob]

@learnshare 前面的留言里忘记写项目时间了哈哈，不好意思

[learnshare]

@agoodob 或许只是技术没有更新，这种问题也比较普遍
16 年还在用 jQuery 的项目也算是技术该更新了

[xuwenmang]

PHP 以前用类来封装的时候都被吐槽 PHP 就该有 PHP 的样子~

[Hieast]

过度设计变为简单设计容易，没有设计想做好设计难

[zachlhb]

分层书写，前期可能绝对很复杂，啰嗦，但是当项目越写越大的时候就知道这样写的好处了

[freefcw]

分几层的调用倒是没错，不过它这个也太多了点，一般而言有个三层差不多覆盖 80 的业务了，还是看业务需求实现

[param]

Java 转 Python 的好像也这样

[lsls931011]

我对你们无语， 这不是正常的么。 Web 后端是要分业务层、逻辑层、模型层、服务层互相调用, 为什么要这样写是为了方便以后的维护。 你说的精简代码就是 PHP 就是直接调用 PDO 从数据库获取数据是吧，可是你想想现在产品需求就是简单从数据库获取 APPID 下所有广告，那么你能保证以后产品不会针对这个接口提出更多需求， 到时候你说的精简反而给自己留下坑。 还有查询数据库尽量减少使用 * ， 因为这相比较查询特定字段要慢得多

[lihongjie0209]

分层是没问题的, 但是分太多有点过度设计了

[carakan]

这个个锅..java 不背..只能说人有点思维定势...分层不假..接口过于细化..有点问题了(不按当前实际情况

[linuxchild]

hhha 让我想起来身边有 Java Coder 写的 Python 命名全部驼峰

[watzds]

Java 很多人每个 DAO 对应一个 service，这种我是不喜欢的，方法还一样

[AccIdent]

楼上说的挺多了，但是有一点没有提到，如果不做封装不做分层，测试代码还写的下去吗？楼主可以从这个角度考虑下

[simo]

不谈应用背景，没有意义。
简单的按照业务量来分大、中、小工程，即使同一个框架，分层设计也会不同

[components]

楼主应该简单介绍下。应用场景，业务规模，架构设计

[james2013]

PHP 不懂,只是说下 Java 的感受.
这种是 Java 后端的一把梭,方便解耦,小项目觉得多余,项目大了维护性还是比较好的.如下
request ->xx Controller ->xxService(接口,空方法)->xxServiceImpl(具体实现方法,调用 xxDao)

[yylucifer]

我第一感觉就是解耦。

[wdlth]

这不是什么 Java 的问题，这是 DI、IOC 的问题。

[m939594960]

1.首先第一点关于这个 * 的问题，laravel 的 model 带了一个属性叫 $hidden 的数组，如果我数据库添加字段比较敏感，无论我用不用*都会在这个 hidden 数组中添加，在结果里的字段不会显示出来，也就是安全应该不会有太大的问题，性能问题另说
2.关于这个分几层的问题，我觉得还得具体看项目，因为有很多的项目都是逻辑很简单的，例如这种论坛的程序，基本就是 CURD，一个方法里可能都写不到 4~5 行，这种情况我觉得就完全没有必要分层，不必写的一个根据 ID 查帖子的程序要好几层。但是有很多程序逻辑并没有那么简单，例如一些金融的系统，客户管理等等，里面逻辑、查询等等可能都特别复杂，这种要是不分层也完全没办法写得下去，而且分层了之后无论是单元测试、分工还是将来的修改都非常有好处。当然还有些情况我写的时候一部分的控制器要分层，另一部分就懒得分了。
3.关于性能问题,我觉得吧，上了 opcache 之后应该也没有太大的问题，而且 PHP 这个语言，要是为了性能让编写的舒适感都没了，不能根据自己需求来调整的话，那干脆别用 PHP 了，所以我觉得写几层都不是问题，况且现在还有 swoole 这种东西，性能更不是问题了。
4.我觉得 JAVA 转到 PHP 最令人反感的是一些地方的命名，例如 Dao,Bean 啥的命名非常烦人，因为这种命名都是类库的名字（猜测）和实际的用途没有一点关系。

[blless]

代码分层一开始设计好了 后期比较好改需求。不过我会根据实际情况要不要写那么多层，简单一开始只有一两个固定需求就懒得拆了。分层设计跟语言无关吧

[blless]

还有分层便于写测试用例 mock 等等等等…我感觉写 php 的是不是比较不爱写测试用例啥的…

[MonoLogueChi]

我不懂 PHP，但是感觉这样设计没毛病啊

[abcbuzhiming]

select * 到底有啥问题，不是敏感数据需要每个字段名都输入一遍？
另外架构设计者玩意，是要看应用环境定的，简单的环境自然不分层，复杂点的应用场景不分层你试试。另外，也要考虑到项目生命周期，如果一个项目的应用前景不明朗，就是为了快速上线试错的，搞不好就死了，这样的项目搞那么复杂干啥，赶紧怎么简单怎么来，做上去试试再说，真起来了再重构（大部分都是没起来直接死了）。起不来要那么多“可维护，可迭代”的架构做啥呢

[udqg3v0ZL6h6sHu8]

@agoodob 可能为了兼容 IE8-吧。

[chocotan]

写 java 的正常操作
之前一个工程要从.net 改成 java，我们看代码都惊了，几乎所有逻辑都写在 controller 里

[realpg]

知足吧
曾经面试过一个 java 商业软件的 转 PHP 网站开发

对数据库应用方面 提了一个简单的小问题 表结构没法直接查询获得目标结果 考点是怎么设计循环查询少性能高之类 算是一种日常数据库优化思维的考验

这大哥闷头抠了半天 给我一个将近 4KB 的 SQL 语句，一条语句解决问题，表现的超级牛逼的样子，嵌套了 N 层，临时表 N 个……

[st2udio]

Laravel 不就如此嘛

[zqguo]

确实写 Java 的是这样，其实有时感觉太固定了，看看 Python 多简洁。

[twotiger]

不是 java 的问题,在复杂的项目中,分层是必要的,只要不过度设计,还有如果之前的项目都分层了,最好还是按照之前的逻辑来.

[xiaoxlm]

应该根据项目的大小来决定设计的复杂度。用 PHP 写的很多都是小项目，确实不用过度设计。其实 JAVA 很多设计理念很好的，不应该只把格局放在脚本语言上。应该相互学习！

[everhythm]

一般的产品项目，代码结构分层主要目的是提高开发效率，次要才是降低维护成本

接 lz 的例子，从数据库取东西分 2 层就好，service 放业务逻辑，model 操作数据库不放业务逻辑
这样 model 可复用，service 不可复用，如果其他地方需要复用业务逻辑，又有 2 种做法

1. 将 service 层再拆出 1 层 logic 供复用（类似 lz 的情况）
2. 重复写 1 份

很明显第 1 种开发效率会低，第 2 中维护成本会高，但这里我觉得只是简单查 1 个表的话，没必要搞 n 多层

[notreami]

框架合理性，可以讨论讨论，就 lz 说的这些不足以说明什么，管中窥豹的评价，并没有什么意义。lz 整想讨论这个，麻烦将框架的全貌图发上来，局部设计的复杂，有可能是为了其他设计的让步呢？
然而，lz 截图，写的代码，确实是没有考虑性能，维护问题。

[sensui7]

其实各有道理, 但是 select * 这是硬伤, 你没得辩.