写点什么

Spring Web 应用的最大瑕疵

  • 2013-11-08
  • 本文字数:2065 字

    阅读完需:约 7 分钟

众所周知, 现在的 Spring 框架已经成为构建企业级 Java 应用事实上的标准了,众多的企业项目都构建在 Spring 项目及其子项目之上,特别是 Java Web 项目,很多都使用了 Spring 并且遵循着 Web、Service、Dao 这样的分层原则,下层向上层提供服务;不过 Petri Kainulainen 在其博客中却指出了众多 Spring Web 应用的最大瑕疵,请继续阅读看看文中所提到的问题是否也出现在你的项目当中。

使用 Spring 框架构建应用的开发者很乐于谈论依赖注入的好处。但遗憾的是,他们很多人并没有在其应用中很好地利用其优势,如单一职责原则关注分离原则。如果仔细看看基于 Spring 的 Web 应用,你会发现很多都是使用如下这些常见且错误的设计原则来实现的:

  • 领域模型对象只是用来存储应用的数据。换句话说,领域模型使用了贫血模型这种反模式。
  • 业务逻辑位于服务层中,管理域对象的数据。
  • 在服务层中,应用的每个实体对应一个服务类。

可问题是:如果这种做法很普遍,那为什么说是不对的呢?下面来阐述一下。

旧习难改

Spring Web 应用之所以看起来是这个样子原因在于这是人们长久以来的做法,旧习难改,特别是在高级开发者或是软件架构师强制开发人员这样做的时候。问题在于这些人非常擅于捍卫自己的观点。他们喜欢的一个论调就是应用应该遵循关注分离原则,因为它被划分成了几个层次,每个层次都有自己具体的职责。

一个典型的 Spring Web 应用会有如下几个层次:

  • Web 层:负责处理用户的输入并向用户返回正确的响应。Web 层只会与服务层通信。
  • 服务层:作为事务边界。它还负责授权并包含了应用的业务逻辑。服务层管理着领域对象模型并且与其他服务及存储层通信。
  • 存储 / 数据访问层:负责与所用的数据存储进行通信。

关注分离原则的定义是这样的:关注分离(Soc)是一种将计算机程序划分到不同部分的一种设计原则,这样每一部分都会有单独的关注点。虽然一个典型的 Spring Web 应用也在一定程度上遵循了这个原则,不过实际情况却是应用拥有一个整体的服务层,它包含了太多的职责了。更具体一些,服务层主要有两个问题:

首先,应用的业务逻辑来自于服务层。

这是个问题,因为业务逻辑散落在服务层。如果需要查看某个业务规则是如何实现的,我们需要先找到它才行,这可不是那么轻松的事情。此外,如果有多个服务类都需要相同的业务规则,那么开发人员很可能会将这个业务规则从一个服务复制到另一个服务中,这会导致维护的梦魇。

其次,每个领域模型类在服务层中都有一个服务类。

这违背了单一职责原则:单一职责原则表明每个类都应该只有一个职责,这个职责应该完全被这个类所封装。它的所有服务都应该与这个职责保持一致。

服务类存在大量的依赖和大量的循环依赖。一个典型的 Spring Web 应用的服务层没有包含只拥有一个职责的松耦合的服务,它更像是一个紧耦合的大量服务的集合。这使得它很难理解、维护与重用。看起来有点苛刻,不过服务层经常是 Spring Web 应用最容易出现问题的一环。幸好对我们来说还存在着希望。

推翻

目前的状况并不好,不过也不是完全没有希望的。下面我们来看看如何打破旧有的习惯。

首先,我们需要将应用的业务逻辑从服务层移动到领域模型类中。

为何要这么做呢,看看下面这个例子:

假设我是个服务类,你是个领域模型对象。如果我告诉你从房顶跳下来,那么你是否会拒绝呢?

将服务层的业务逻辑移动到领域模型类中有如下 3 个好处:

  • 根据合理的方式划分代码的职责。服务层会负责应用的逻辑,而领域模型类则负责业务逻辑。
  • 应用的业务逻辑只会位于一处。如果需要验证特定的业务规则是如何实现的,我们总是知道该去哪里寻找。
  • 服务层的源代码将会变得更加整洁,再不会包含任何复制粘贴的代码了。

其次,我们需要将特定于实体的服务划分为更小的服务,每个服务只有一个目标。

比如说,如果应用有一个服务类,它为与用户帐户相关的人与操作提供了 CRUD 操作,那么我们就应该将其划分到两个单独的服务类中:

  • 第 1 个服务提供人的 CRUD 操作。
  • 第 2 个服务提供与用户帐户相关的操作。

这么做有如下 3 个好处:

  • 每个服务类都有一套合理的职责。
  • 每个服务类的依赖会更少,这意味着他们不再是紧耦合的庞然大物了。他们是更加小巧且松耦合的组件。
  • 服务类更易于理解、维护与重用。

这两个简单的步骤可以帮助我们清理应用的架构,提升开发者的生产力和幸福度。现在,我们想知道如果所有这些都是必要的,那么该何时解决这些问题呢?

有时生命是黑白的

我经常听到有人说我们不应该过多的关注于“架构”,因为我们的应用很小并且很简单。虽然这个论调有一定的正确性,不过我们必须要记住一开始很小的项目最后会变得很大。如果不考虑这种情况,那么一旦发生状况,我们就会陷入到巨大的麻烦当中。在未知的水域中航行可不是个好做法,但我们必须要知道,泰坦尼克号在撞到冰山沉没时是在熟悉的航线中航行的。这种事情也会发生在我们的应用中。当事情变得无法控制时,我们必须要有勇气说不。

如果你打算改变,那么我推荐你阅读一下Olivier Gierke 所写的“ Whoops! Where did my architecture ”(或是观看他在 SpringOne2GX 上关于这个项目的演讲)。但请注意,习惯的力量还是很强大的。

2013-11-08 11:329711
用户头像

发布了 88 篇内容, 共 266.7 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

阿里云中间件首席架构师李小平:企业为什么需要云原生?

阿里巴巴中间件

2021年5月云主机性能评测报告出炉,华为云跃居榜首

博睿数据

云主机 博睿数据 博睿指数

Flink User-Defined Source

Alex🐒

flink 翻译 Flink扩展 flink1.13

第六课作业

杰语

2021年版,拼多多/阿里/今日头条/京东 Java面经大合集(含答案)

Java架构师迁哥

公安情报研判分析系统解决方案,合成作战系统搭建

终端架构深研,CodeDay 成都站等你

蚂蚁集团移动开发平台 mPaaS

flutter mPaaS Codeday Meetup

细细阅读,3张图带你理解,零拷贝,mmap和sendFile

奔着腾讯去

c++ Linux Mmap C++后台开发 网络io

数据库设计的 10 个最佳实践

xcbeyond

数据库 数据库设计 6月日更

分布式能解决一切问题吗?百度架构师为你解答架构真正奥义!

Java架构师迁哥

网易有道开源EMLL:高性能端侧机器学习计算库,大幅提高计算性能

有道技术团队

人工智能 机器学习 高性能计算 端侧AI

专科小伙豪取三杀,斩获阿里、京东和蚂蚁Java岗offer的原因找到了!

北游学Java

Java 面试

[译] 规避供应商以及特定版本的 VM Bugs

Antway

6月日更

5W1H聊开源之Who/When/Where——谁在何时何地“发明”了开源?

禅道项目管理

Linux 开源 软件

🌏【架构师指南】分布式技术知识点总结(下)

码界西柚

分布式 架构设计 6月日更

移动开发iOS,薪资如何?待遇怎样!

ios开发 iOS 知识体系

必须加强对电商促销节的监管:保障普通消费者合法权益

石头IT视角

阿里云边缘容器服务ACK@Edge 通过33项测评,拿到“2021云边协同能力认证”

阿里巴巴中间件

新思科技宣布收购 Code Dx公司 添加软件漏洞关联、优先级和合并风险报告

InfoQ_434670063458

新思科技

WebRTC 传输安全机制第二话:深入显出 SRTP 协议

阿里云CloudImagine

音视频 WebRTC 通信 流媒体开发 SRS流媒体服务器

搭建Prometheus+Grafana的云平台监控系统

学神来啦

云计算 Linux 运维 开发日志

80后自立门户,90后异军突起,中国投资新势力加速崛起 | 创业邦2021年40位40岁以下投资人重磅发布

创业邦

创业

iOS开发21年6月面试总结(未完待续~)

iOSer

ios 面试 ios开发 iOS 知识体系

测试工程师如何收拾交接项目的烂摊子

陈磊@Criss

测试

凭这份pdf每天花2小时学习,3个月后拿下阿里/美团/京东等offer

Java 程序员 架构 面试

谁说双非本就一定无缘阿里!(四年crud经验已拿下P7)面经分享

Java 程序员 架构 面试 计算机

深入浅出 LVS 负载均衡(三)实操 NAT、DR 模型

UCloud技术

关于Redis分布式锁的那些事

Hex

redis 后端

在线图片坐标拾取工具

入门小站

WebRTC学习—WebRTC详解

Linux服务器开发

音视频 WebRTC ffmpeg SRS流媒体服务器

WWDC21 给开发者最重要的7条新信息

阿里巴巴大淘宝技术

开发者 WWDC21

Spring Web应用的最大瑕疵_架构_张龙_InfoQ精选文章