首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

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

  •  
  •   KomeijiSatori · 2018-05-19 16:10:47 +08:00 · 8562 次点击
    这是一个创建于 541 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    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
    wujichao   2018-05-19 16:26:46 +08:00
    似乎不建议直接 select *
        5
    KomeijiSatori   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   ♥ 2
        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   ♥ 4
    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
    orzzyd   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 * 这是硬伤, 你没得辩.
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4069 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 33ms · UTC 03:45 · PVG 11:45 · LAX 19:45 · JFK 22:45
    ♥ Do have faith in what you're doing.