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

调用

数据库

获取

service

59 条回复 • 2018-05-21 09:49:11 +08:00

1

liprais

2018-05-19 16:12:15 +08:00 via iPhone

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

2

chinvo

2018-05-19 16:16:50 +08:00

如果那是领导，赶紧跑路

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

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

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

3

yiqiao

2018-05-19 16:24:05 +08:00

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

4

CDuXZMAPgHp1q9ew

2018-05-19 16:26:46 +08:00

似乎不建议直接 select *

5

KomeijiSatori

OP

2018-05-19 16:26:56 +08:00

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

6

agoodob

2018-05-19 16:28:53 +08:00

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

7

agoodob

2018-05-19 16:29:46 +08:00

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

8

silencefent

2018-05-19 16:34:35 +08:00

没错吧，laravel 都这么写

9

zjsxwc

2018-05-19 16:34:41 +08:00

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

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

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

10

learnshare

2018-05-19 16:36:46 +08:00

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

11

newtype0092

2018-05-19 16:37:35 +08:00

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

12

fyibmsd

2018-05-19 16:41:31 +08:00

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

13

fyibmsd

2018-05-19 16:43:01 +08:00

3

[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/)

14

oovveeaarr

2018-05-19 16:44:43 +08:00

2

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

15

gaolycn

2018-05-19 16:56:22 +08:00 via Android

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

16

ranwu

2018-05-19 17:01:08 +08:00

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

17

aa6563679

2018-05-19 17:06:37 +08:00 via iPhone

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

18

xrlin

2018-05-19 17:09:24 +08:00

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

19

janxin

2018-05-19 17:14:16 +08:00 via iPad

我觉得就是*的问题

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

20

instein

2018-05-19 17:50:33 +08:00

5

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

21

instein

2018-05-19 17:52:19 +08:00

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

22

bromineMai

2018-05-19 17:54:31 +08:00

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

23

Actrace

2018-05-19 18:18:39 +08:00

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

24

Marfal

2018-05-19 18:26:05 +08:00

我想吐槽一下字体...

25

newtype0092

2018-05-19 18:28:35 +08:00

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

26

agoodob

2018-05-19 18:43:09 +08:00

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

27

agoodob

2018-05-19 18:44:05 +08:00

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

28

learnshare

2018-05-19 18:51:07 +08:00

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

29

xuwenmang

2018-05-19 18:52:12 +08:00

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

30

Hieast

2018-05-19 19:15:41 +08:00

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

31

zachlhb

2018-05-19 19:26:36 +08:00 via Android

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

32

freefcw

2018-05-19 19:26:58 +08:00

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

33

param

2018-05-19 19:36:07 +08:00 via Android

Java 转 Python 的好像也这样

34

lsls931011

2018-05-19 20:24:22 +08:00

3

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

35

lihongjie0209

2018-05-19 20:29:04 +08:00

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

36

carakan

2018-05-19 20:36:20 +08:00

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

37

linuxchild

2018-05-19 21:03:09 +08:00

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

38

watzds

2018-05-19 21:39:44 +08:00 via Android

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

39

AccIdent

2018-05-19 21:45:55 +08:00

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

40

simo

2018-05-19 22:19:17 +08:00

1

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

41

components

2018-05-19 22:52:17 +08:00

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

42

james2013

2018-05-19 23:24:01 +08:00

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

43

yylucifer

2018-05-19 23:33:14 +08:00

我第一感觉就是解耦。

44

wdlth

2018-05-19 23:35:38 +08:00

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

45

m939594960

2018-05-20 00:42:15 +08:00

1

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

46

blless

2018-05-20 00:47:36 +08:00 via Android

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

47

blless

2018-05-20 00:49:50 +08:00 via Android

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

48

MonoLogueChi

2018-05-20 00:54:54 +08:00 via Android

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

49

abcbuzhiming

2018-05-20 09:05:34 +08:00

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

50

udqg3v0ZL6h6sHu8

2018-05-20 09:36:20 +08:00 via iPhone

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

51

chocotan

2018-05-20 09:56:06 +08:00

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

52

realpg

2018-05-20 10:17:17 +08:00

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

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

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

53

st2udio

2018-05-20 10:46:27 +08:00

Laravel 不就如此嘛

54

zqguo

2018-05-20 10:48:12 +08:00

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

55

twotiger

2018-05-20 11:09:42 +08:00

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

56

xiaoxlm

2018-05-20 14:03:16 +08:00

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

57

everhythm

2018-05-20 16:52:50 +08:00

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

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

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

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

58

notreami

2018-05-21 09:30:39 +08:00

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

59

sensui7

2018-05-21 09:49:11 +08:00

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