设计中 横向切割 和 纵向切割

本贴最后更新于 391 天前,其中的信息可能已经时异事殊

自己学习一段时间 Java 代码了,发现现在后端的模式大多都是三层架构,自顶向下的横向切割,而且基本都是 controller、service、dao 这种结构。

其实很多时候会发现一个问题,在某些小应用中,对于 service 来说,都是直接的一句话返回而已,但是却依旧贯彻 三层 分层,即使只有一句话都固执的去使用。为什么不舍得舍去呢?只用两层难道不行嘛?在某些实践中,我就舍掉了 service,减少了很多类不说,思路都会清晰横多,因为不用去维护更多的数据和逻辑了。

而且除了横向切割以外,为什么不能够纵向切割呢?例如以前我们的结构是这样的

+ src
|--- main
  |--- java
    |--- controller
      |--- UserController
    |--- service
      |--- UserService
    |--- entity
      |--- User
    |--- filter
      |--- UserFilter
    |--- dao
      |--- UserDao

那我们可以不可以这样恩

|--- main
  |--- java
    |--- user
      |--- UserController
      |--- UserService (个人觉得可以省掉)
      |--- UserDao
    |--- entity
      |--- User

这样的话个人觉得可以有几个好处:

  1. 专注于某个模块的实现
  2. 全栈工程师更加方便的 “一捅到底”
  3. 问题定位十分方便
  4. 将功能分模块细化

这样的设计我觉得也很棒啊,但是后端却很少见人实践,后面的项目就打算自己实践一下。

  • 设计
    98 引用 • 719 回帖 • 1 关注
  • MVC
    7 引用 • 113 回帖
6 回帖
请输入回帖内容...
  • 88250

    这是包或者说是组件的设计原则决定的,归根结底就是

    • 高内聚、低耦合
    • 重用

    举个例子,DAO 必须要具有高度的可重用性,所以 xxxDao 都放在一个包里可以提升这个包的内聚,降低对外耦合,从何提升这个包的设计质量。如果分散到多个包里,那其他代码对 Dao 的依赖会变得错综复杂,从而打破每个包的内聚。

    另外,大部分业务逻辑实现都是通过“事务脚本”(《企业应用架构的模式》PoEAA)完成,通过 Service 层进行数据库事务封装,省掉 Srv 也不是不行,因为可以直接在 Ctl 里封装事务,具体看整体业务复杂度而言。一般来说为了保持整体设计的一致性,会保留 Srv 层,因为一开始可能业务简单,Srv 里面每个方法就一两句调用 Dao 的,但随着业务复杂起来,Srv 的实现就会丰富起来,这时也需要一定的重用,所以 Srv 层会从设计一开始就保留。

    另外,“过早的优化是万恶之源”,无论这个优化是指的简化还是复杂化,折中方案是设计上永恒的追求。

    1 回复
  • xflash

    这让我想起了好多年前大家都热衷于讨论领域模型,什么是贫血、充血、涨血等等。其实没什么意义,好的设计是大家都能理解的设计,好的设计是打开 IDE 就能找到写代码地方的设计。对于一个普通 CRUD 业务的项目,要为其写一堆“架构”文档才能让开发人员理解,那么做设计的人非傻即坏。

  • lizhongyue248

    最后总结到了一点

    不能太简,因为可能会为后来留下许多难以完成的事。

    不能太复杂,因为可能前期会花一些无用功。

    所以折中最为理想。

    但是如果换一个思路,横向切割保留了包的内聚,那么纵向切割是不是保留了模块的内聚呢?那么也就是提高了这个模块的设计质量。特别现在前端也是模块化/组件化,那么这样其实对应过来反而会好许多。

    而且,如果这些模块的操作不是与实体类对应的呢?而是与功能进行对应的呢?来考虑这种模块结构

    |--- main
      |--- java
        |--- auth
          |--- AuthController 授权的处理,登录/注册/找回密码等
          |--- AuthDao 授权操作数据库
        |--- entity
          |--- User
          |--- Role
    
    

    AuthDao 不一定只操作 User 表,他也要操作 Role 表,但是他可以选择是否调用 User 、Role 的 Dao,或者就是直接对这两张表进行操作,那么模块之间其实并没有太多的耦合了,而都是各个模块之间完成自己的事情,并不需要去调来调去。

    这样的设计完全颠覆了以前的横向切割的设计,是不是可取性更高呢?

    1 回复
  • 88250

    这个时候 AuthDao 其实就是 AuthService。Dao 一般只操作单表,Service 组合操作 Dao。

  • someone45057

    我还在某些地方看到这两个名词叫:水平拆分跟垂直拆分
    其实细细想来项目的发展过程就是水平跟垂直之间的平衡

    1 回复
  • lizhongyue248

    是的,各有所长各有所短,怎么平衡还是看需求来 ~

请输入回帖内容 ...