10x 程序员工作法
郑晔
开源项目 Moco 作者
53432 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

35 | 总是在说MVC分层架构,但你真的理解分层吗?

总结时刻
构建你的抽象
有抽象有发展
无处不在的分层
MVC架构
设计上的分解
分层架构和抽象

该思维导图由 AI 生成,仅供参考

你好,我是郑晔。
作为程序员,你一定听说过分层,比如,最常见的 Java 服务端应用的三层结构,在《15 | 一起练习:手把手带你分解任务》中,我曾提到过:
数据访问层,按照传统的说法,叫 DAO(Data Access Object,数据访问对象),按照领域驱动开发的术语,称之为 Repository;
服务层,提供应用服务;
资源层,提供对外访问的资源,采用传统做法就是 Controller。
这几乎成为了写 Java 服务的标准模式。但不知道你有没有想过,为什么要分层呢?

设计上的分解

其实,分层并不是一个特别符合直觉的做法,符合直觉的做法应该是直接写在一起。
在编程框架还不是特别流行的时候,人们就是直接把页面和逻辑混在一起写的。如果你有机会看看写得不算理想的 PHP 程序,这种现象还是大概率会出现的。
即便像 Java 这个如此重视架构的社区,分层也是很久之后才出现的,早期的 JSP 和 PHP 并没有什么本质区别。
那为什么要分层呢?原因很简单,当代码复杂到一定程度,人们维护代码的难度就急剧上升。一旦出现任何问题,在所有一切都混在一起的代码中定位问题,本质上就是一个“大海捞针”的活。
前面讲任务分解的时候,我不断在强调的观点就是,人们擅长解决的是小问题,大问题怎么办?拆小了就好。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了分层架构的技术特点以及在软件开发中的重要性和应用价值。作者从设计上的分解出发,解释了分层架构的必要性,并以Java服务端应用的三层结构为例,详细介绍了分层架构的来龙去脉。文章强调了构建抽象的重要性,指出分层抽象在计算机领域无处不在,为构建更复杂的东西提供了基础。作者建议读者将精力重点放在构建自己的领域模型上,因为它才是工作最核心、不易变的东西。总的来说,本文通过深入浅出的方式解释了分层架构的技术特点,以及其在软件开发中的重要性和应用价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • 西西弗与卡夫卡
    万维钢有期节目里提到芯片设计时讲到了分层以及模型的概念。分层或模型,实质是因为人的认知能力有限不得已而为之的。学习计算机,我们都知道晶体管,即便早就忘了它的原理。实际上晶体管涉及非常深奥的物理学知识,这是绝大多数人一辈子都不需要了解的物理学。抛开复杂艰深的物理学,晶体管的本质却很简单,它就是一个包含通和不通两个状态的开关,这就是它构建的模型。 在开关的模型基础之上,信息论的创立者香农用一篇硕士论文构建了逻辑门这层。他证明了可以用最简单的开关,实现所有逻辑运算。 逻辑运算层次之上,就是我们所知道的CPU模型。再往上,就是我们所熟悉的信息世界

    作者回复: 同是精英日课的读者,这篇内容还真的是受到万老师的影响写下的。

    2019-04-01
    3
    75
  • 春之绿野
    文章有些地方看不懂,不太懂领域对象什么的

    作者回复: 核心模型,就是当你的软件去掉它,就不是这个软件了。比如,如果没有商品和订单,电商就玩不转了,但如果它不支持高并发,其实没什么影响。

    2019-09-15
    13
  • desmond
    学了REST和DDD,感觉两者有相通的地方:两者都以数据(一个是资源,另外一个是领域对象)为中心,并制定一套标准的数据操作(一个是HTTP Verb,另外一个我项目主要用JPA这一套);而核心是业务建模。

    作者回复: 你的理解很棒!

    2019-04-02
    11
  • Wei
    分享一下自己的经历,best practices 其实在不同时期有不同的理解,有时候甚至变化很大,我自己也有迷惑的时候。 我是做ror出身的,rails 就是标准的MVC,再加上一个helper目录; 初入行时候接触的项目,controller都很臃肿,后来,提倡的是 thin controller, fat model, 于是大家又把逻辑搬到model里面;于是model又变得非常臃肿,里面包括了很多业务逻辑,耦合太高,写起测试来非常痛苦; 另外,原本helper只应该放关于view的method, 却很快变成了垃圾桶,很多不是view相关的方法都扔在了helper目录下,甚至很多controller要include 其他controller 对应的helper, 只是因为那里定义了一个可以用到的方法。 再后来,有了presenter的概念,helper目录基本就不用了;每个controller都有对应都presenter,再有,就是建立了service的目录,把业务逻辑从model里面抽离处理; 这样的结构稍微清洁了一点,测试也好写了很多。 但是在我看来,我们项目presenter/services这种分层没有什么标准,有些同事还是把这种分层当作万能垃圾桶,什么都建一个,甚至业务/运算都扔在presenter里面;services 的分层也是一个问题,很多只是根据model的来分,而不是业务; 最近有看了一下elixir对应的phoenix , 它引入了context的概念,更偏重于业务划分, 我感觉这是一个比rails 更合理的分层。 PS:非常喜欢老师的这个课程,收益良多,能否建立微信群/slack/小密圈 之类的以便课程结束后能继续与老师和各位同行交流。 谢谢

    作者回复: 多谢你的分享!后续的安排看编辑怎么协调吧。

    2019-04-04
    2
    10
  • 布衣骇客
    老师提到的直接把第三方类库的字段直接使用,导致bug层出不穷,这个真的是深受其害,线上程序莫名bug,原来是第三方修改或者擅自把字段等出现问题,改来改去,最后还是用类似老师提出那种转化本地对象再使用,最后做了类似一个防腐层那种解决问题。实际才出的坑总结到这么个东西,就是类似老师提出的模型概念

    作者回复: 道理很简单,痛过才知道。

    2019-04-01
    10
  • 王维
    老师在这篇文章里其实主要讲的是DDD,文章在讲到Model时,有一个Model,老师没有讲到,那就是ViewModel,即供视图使用的模型。以前我做过总结,模型应该有三种:领域模型(DDD Model),数据访问模型(Data Access Model)和视图模型(View Model),请老师指教。

    作者回复: 如果以这个标准看,模型就太多了,与外部系统的通信要不要有个模型呢?ViewModel只是针对显示领域的模型,数据访问模型只是针对数据访问的模型,领域模型才是系统核心的模型。

    2020-03-22
    2
    5
  • 码农Kevin亮
    请问老师,在jdk的集合框架中常常会在实现类内部维护一个内部类,比如HashMap内部有个Node内部类,这算领域对象么?

    作者回复: 在通常的讨论中,这是不算的。

    2019-09-02
    4
  • kevin
    从分层一步步说到领域层的设计重要性,学起来很过瘾。文末留言万老师关于晶体管的设计很精彩

    作者回复: 欢迎把它分享给你的朋友!

    2019-04-07
    4
  • 0xABC
    目前对DDD还是一头雾水,尤其对领域模型的抽象和划分,郑老师能不能分析一些实际的案例,这样能有一个更直观的体验

    作者回复: 可以去看看《软件设计之美》,增进一下对于设计的理解。

    2019-04-01
    2
  • wuhulala
    分层 = 抽象,软件系统的横向模块划分,纵向逻辑分层,确实是一种抽象的实际应用

    作者回复: 分层不等于抽象,但分层是基于抽象构建起来的。

    2020-03-19
    1
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部