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

[KomeijiSatori]

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

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

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

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

[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 * 这是硬伤, 你没得辩.