一个简单的从数据库里获取指定 APPID 下所有广告的接口,内部封装了一大堆神奇的东西
从数据库里拉取东西先要调用 getAdvertService 获取到获取广告的 Service,然后这个 Service 又要获取 AdvertLogic,然后 AdvertLogic 里又调用 AdvertPosLogic,然后 AdvertPosLogic 里才调用 AdvertPosModel 来连接数据库查询。。
然后我精简成几行代码还被吐槽了。。。
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 @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 下就好 |
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 * 这是硬伤, 你没得辩.
|