专栏首页搬砖记录关于“代码分层”的思考

关于“代码分层”的思考

在很多语言中,都会利用“目录”来规范开发者分层的逻辑。 比如Javaweb中,会将目录分为Controller,Service,Dao,Model等等。

利用目录的形式对开发者进行约束,能够使代码整体结构更加清晰,功能分工更加明确。

我一直“以为”我对分层的感受能力还是很强的,但是回顾上星期写的代码,才让我感觉我对分层的理解一直停留在表面。

大家都知道: 在逻辑上,可能使用概念分层,比如AO,DAO; 在功能上,可能使用模块名进行约束,比如xxx_order、xxx_log; 进一步到代码上,利用目录进行分层,比如xxx_logic、xxx_model;

但是,我觉得上述的方式对于开发者来说(尤其是团队协作),都太宽泛了,对实际开发行为上难以进行“接口级别的约束”,但团队开发,互调接口却是很常见的。 如果在一开始并没有明确、协商好接口的参数返回值,就需要开发者自己理解不同层面的接口应该传递哪种粒度的对象。(我觉得主导者预先设计好接口是必要的,但是执行者自己也能理解其深意也是必须的)。

以我当前参与的项目为例,我需要实现model层(我理解为数据访问层)的逻辑功能,(代码)分层如下:

顶层的Account提供给外部使用,封装了账户的所有操作(流水只是账户变动的附加记录,理论上也是Account本身的熟悉),Account再利用AccountTable操作具体的账户表,利用DetailTable操作具体的流水表。

分层非常清晰,但是真正写起来会有很多“操作粒度”层面的问题(设计者没有提供接口的参数,需要我自己去思考)。 比如:

  1. 修改时的幂等校验,放在Account里面还是两个Table对象里面?为什么?
  2. 可以将查询的参数filter对外提供吗?在接口上作为参数传递进来(filter类似一个Map,相当于mysql where条件的实例)
  3. 不同的数据状态,在Account就进行(统一)分支还是下沉到两个Table中? ……

上面的问题似乎跟分层无关,但是我觉得这是“概念分层”无法掌控的细粒度分层。

  1. 如果把幂等校验放在Account里面,需要同时对AccountTable和DetailTable进行幂等校验,这时候需要操作两次数据库。将“意外拦截在了最外层”似乎很美好。 但是,当幂等校验通过后,进入到两个Table中之后,又要重复操作一次数据库,拿到在Account就已经拿到的对象,这显然非常不好,当然可以选择在Account就把参数传递下去,但是一开始没想到呢?
  2. 我一开始就是把filter提供给了外部,这样对于查询,我只需要写一个接口,外部想要查询什么,自己构造filter即可。但是这个很容易想到,破坏了功能上的封装性,调用者需要熟悉库表结构才能准确操作该接口,这显然加大了整体的开发难度。
  3. 我一开始是在Account中进行统一分层,但是统一分层会使得局部代码快速膨胀,分支过多难以理解,结构不清晰,最终选择各个方法自行处理状态分支。

我觉得,分层应该不仅仅是宏观层面的概念,不能停留在目录分层的层面。 对个人来说,实现时的逻辑分层更重要,开发阶段就应该注意逻辑分层的抉择,尽量满足开闭原则,才能写出容易理解、结构清晰、易扩展的代码。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 关于分词的一些思考

    我发现分词问题并不存在适用于所有领域的通用解决方案,之前我一直以为给词库里加一些专业词汇能够解决一些特定专业的问题,现在一想自己还是太naive了。举两个例子:...

    云时之间
  • 关于supervisor的思考

    Supervisor (http://supervisord.org) 是一个用 Python 写的进程管理工具,可以很方便的用来启动、重启、关闭进程(不仅仅是...

    追马
  • 关于分布式“缓存”的思考

    本文从缓存的分类、同步和空查询三个问题分享下对分布式缓存的一些想法,抛砖引玉。

    郝阳
  • 关于eth gas的思考

    rectinajh
  • 关于“开源”的思考

    最近,我经历了一次有意思的讨论。讨论的主题是代码开源,尤其是指那些用作商业用途的代码,比如用于创造你自己的产品或者服务的代码。以下就是这次讨论所得的,对“开源”...

    哲洛不闹
  • 关于数据分析的一点思考

    之前看过一些产品经理的书,不同时期好产品的定义是不相同的,但是相同的是产品经理都需要做到三要素:用户体验、企业需求和技术。仔细思考其中的逻辑,发现这是将产品确定...

    企鹅号小编
  • 关于分段免杀执行的思考

    我们在写shellcode时候,做分段免杀执行时,如何做到边解码然后执行再调用解码,解码后再执行?就是分段执行而且解密的密钥是不一样的,对于这个问题,我们应该想...

    FB客服
  • 关于逻辑、数学和编程的深层次思考

    众所周知,编程离不开数学和逻辑。诚然,很多程序员数学能力并不强,也没有系统的逻辑能力。但是,他们在无意识中,日常工作中,有意无意的就在使用逻辑和数学,并将它们运...

    三哥
  • 一场关于代码注释的争执,引发的三点思考

    “提倡加注释,但不能滥用。我们开发流程中会有Code Review过程,这样每个人都将了解好的注释是什么样的,同时你遇到不好的代码注释,也需要告诉他如何改进。”

    架构精进之路
  • 关于risc-v启动部分思考

    risc-v的架构有着非常鲜明的特点,如果看过arm,aarch64,mips等架构的一些架构手册的基础知识,再看risc-v的芯片的架构设计,就会觉得非常有意...

    bigmagic
  • [C#]关于DataDirectory的一些思考

    笔者在使用Entity Framework中的Scaffolding机制自动创建拓展名为mdf的数据库及表单时,遇到如下的错误:

    CNXY
  • 关于5G 的十点思考

    本文为邬贺铨院士为《中兴通讯技术》杂志撰写的2020年卷首特稿,边缘计算社区经过授权发布,全文共4556字,内容非常干,预计阅读12分钟。

    边缘计算
  • 一篇关于 SaaS 的思考

    与其说是一篇针对SaaS的思考,不如说是读两本书后的思考。SaaS的知名度要比 PaaS \ IaaS更高,大概是其技术门槛低,从业者众多,更容易与商业活动在一...

    MavenTalker
  • 关于值对象的思考

      但是我们在操控类的过程中,自己不小心或第三方接口使用者误调用了set方法导致MyClass类内状态发生变化,这个是我们不想要的。

    Qt君
  • 关于CodeReview的一些思考

    上图为[产品迭代开发协作流程],其中我们在 Demo 本次迭代之前会对开发人员的代码进行评审,所以今天就聊一下关于CodeReview的一些思考。

    用户5397975
  • 关于前端哈希加密密码的思考

    为了防止用户或者管理员的密码泄漏或者数据库信息泄漏出去,web应用普遍采用了在后端将密码哈希以后存储在数据库中,前端提供密码,由后端进行哈希后与数据库进行对比,...

    caoayu
  • 关于线索评分模型的一些思考

    关于线索评分大家比较熟悉的一个模型是预算(Budget)、授权(Authority)、需求(Need)和时间表(Time Frame),如果客户有足够的预算,有...

    臭豆腐
  • 关于任务调度的思考

    其实对于Celery来说,网络上的资源和文档其实还是比较匮乏的,能够坚持坐下来,能够维护起来这样一个项目,确实不易。

    jeanron100
  • 关于框架的一些思考

    如果你的团队很小并且在软件开发领域也没什么经验,那么放下包袱使用开源框架吧(OSS Framework),但是如果你有一个很大而且有丰富经验的团队,那么最好还是...

    大江小浪

扫码关注云+社区

领取腾讯云代金券