- 博客(29)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 小架构step系列29：校验注解的组合
如果遇到某些属性需要多种校验，比如需要非空、符合某正则表达式、长度不能超过某值等，如果这种属性只有有限几个，那么手工把对应的校验注解都加上即可。但如果这种属性比较多，那么重复加这些校验注解，也是一种代码重复。hibernate-validator包提供了一种组合注解的方式，来解决上面场景的问题。
2025-07-30 00:48:33
208
原创 小架构step系列28：自定义校验注解
hibernate-validator提供了很多内置的校验注解（如@NotNull），还提供了可自定义校验注解的机制，这个对业务系统会比较方便。把一些通用的校验变成校验注解，方便各个业务使用，正是框架应该做的事情，本文了解一下自定义校验注解的机制。在查找请求参数对象哪里配置了校验相关的注解的时候，会把有校验相关的注解标记的字段/方法/类的信息封装到ConstraintDescriptorImpl中。
2025-07-28 20:50:42
764
原创 小架构step系列27：Hibernate提供的validator
直接使用Spring提供的Validation机制来校验请求参数比较麻烦，还好hibernate-validator包提供了注解的方式，在参数对象的属性上加上对应的注解，即可进行校验，这样就方便多了。本文来了解一下hibernate-validator是如何把Spring的Validation机制扩展成用注解这种便利方式的。
2025-07-27 17:37:22
361
原创 小架构step系列26：Spring提供的validator
对于Web服务，需要对请求的参数进行校验，可以对不合法的参数进行提示，提高用户体验。也可以防止有人恶意用一些非法的参数对网站造成破坏。如果是对每个参数都写一段代码来判断值是否合法，那校验的代码就很多，也很繁琐。Spring提供了一套校验机制，先来了解一下。
2025-07-26 22:31:57
1304
原创 小架构step系列25：错误码
一个系统中，可能产生各种各样的错误，对这些错误进行编码。当错误发生时，通过这个错误码就有可能快速判断是什么错误，不一定需要查看代码就可以进行处理，提高问题处理效率。有了统一的错误码，还可以标准化错误信息，方便把错误信息纳入文档管理和对错误信息进行国际化等。没有错误码的管理，开发人员就会按自己的理解处理这些错误。有些直接把堆栈直接反馈到前端页面上，使用看不懂这些信息体验很差，也暴露了堆栈信息有安全风险。
2025-07-25 22:24:12
854
原创 小架构step系列24：功能模块
开发一个业务系统的时候，功能可能非常多，需要对功能进行分组，这里引入“模块”的概念，它就代表着一组功能。对于程序员来说，“模块”这个概念可能容易混淆，比如python语言里也有Module这个概念，翻译为中文也是“模块”，在python中一个模块就是一个代码文件。所以为了有别于其他“模块”，这里专门指功能分组的“功能模块”。如果觉得“模块”这个词不好理解，也可以换成“应用”，本文采用“模块”来说明。
2025-07-24 21:36:39
702
原创 小架构step系列23：加载自定义配置
在业务系统中，自定义配置是比较多的，Spring提供了一套加载配置文件的机制，了解其原理，可以帮助解决一些配置文件的位置问题，更好地使用这些配置文件。
2025-07-23 17:59:47
452
原创 小架构step系列22：加载系统配置
开发一个服务，配置是经常要用到的。如果把配置分一下类，可以分为系统配置、Springboot/Spring自带的配置、业务服务自定义的配置。Spring提供了一整套配置文件的加载，需要了解一下这些配置文件的加载原理，以便更好地使用这些配置文件。这里先关注系统配置。
2025-07-22 08:05:58
280
原创 小架构step系列21：参数和返回值的匹配
从前面看到参数是通过HandlerMethodArgumentResolver进行匹配的，参数有各种各样的形式，比如带注解的、自定义类、基本类型、甚至ServletReqest之类的。返回值则是通过ReturnValueHandler来处理的，返回值也有比较多类型，比如String、Void、Model、自定义类等，如果不是前后端分离的，还可能带View之类的。本文了解一下参数和返回值的匹配原理。
2025-07-21 21:21:03
575
原创 小架构step系列20：请求和响应的扩展点
通过上一篇了解请求和响应的流程，Spring在设计上留了不少扩展点。里面通过查找接口的方式获取的地方，都可以成为一种扩展点，因为只要实现这类接口就可以成为Spring加载的一部分。本文了解一下这些扩展点，方便后面进行扩展。
2025-07-20 22:15:19
1016
原创 小架构step系列19：请求和响应
作为Web程序，通用形式是发起HTTP请求并获取返回的结果，在这个过程中，需要把请求映射到代码的接口上，提供这种接口的类一般称为Controller，也就是需要把请求映射到Controller的接口方法上，把请求的参数映射到接口的参数中，并从接口返回接口处理的结果。在后端渲染页面的场景中，返回的结果需要处理为视图View。而现在更普遍的是前后端分离，返回的结果一般处理为JSON格式的数据，前端拿到这种数据再进行处理和页面的渲染。本文来了解一下这个请求和响应的过程。
2025-07-19 23:16:11
1377
原创 小架构step系列18：工具
在写代码的时候，有很多通用的、与业务无关逻辑，这些一般写成工具类方法。这些工具类方法慢慢地被积累起来，变成了开源包，可以直接使用开源包，而不是自己再花时间来重复造这些轮子。这些工具类的开源包比较多，公司如果没有控制的话，不同的开发人员就会选自己熟悉的开源包，甚至都拿来练练手。这样的后果就是，在一个工程内使用了五花八门的工具类包，维护代码的时候不好维护，如果要升级一些框架包或者扫描漏洞，发现很多包都需要升级或者更改，处理起来工作量比较大。
2025-07-18 22:35:34
825
原创 小架构step系列17：getter-setter-toString
在写代码的时候，有两类bean：一类是专门承载数据而无业务逻辑的bean，如DTO；另外一类是业务模型bean，其既要承载数据也要提供业务逻辑，在DDD中它们就对应于领域模型对象和值对象。这些bean里面可能要提供getter、setter、equals、hashCode、toString，甚至构造方法，这些代码写起来比较无聊，基本都是根据字段来的，属于非常机械化而无技术含量的操作，而这些操作还相当多，增加一个字段或者改一个字段也得响应地进行调整，耗时耗力的。
2025-07-17 19:56:53
825
原创 小架构step系列16：代码文档
现在一般都是前后端分离的模式，后端开发的接口前端需要使用，此时需要提供接口的说明文档给前端；后端开发的接口，后端自己也要测试，甚至需要提供给专门的测试人员测试，此时也需要有具体的接口说明；如果接口是提供给第三方的，为了降低沟通成本，接口文档也是必须的。
2025-07-16 22:20:57
698
原创 小架构step系列15：白盒集成测试
白盒集成测试是spring-test提供的一种不需要启动Web Server就可以触发Controller里的http方法执行的一种方式，由于是从Controller就开始测试，相当于把对应方法后面的一整个流程都进行了测试，这个流程里面可能包含数据库的操作，可能包含文件操作，可能包含中间操作等，如果这些都需要进行配套，比如准备好文件存储的OSS、准备好类似kafka等消息中间件，那这个测试会相当难做，即使能够做也很难多做，成本非常高。本文就列一下这些场景的一种做法，仅供参考。
2025-07-15 22:48:18
914
原创 小架构step系列14：白盒集成测试原理
这里的白盒测试是指开发编写测试代码来进行测试，集成测试是指从Controller开始对http接口调用的整个流程进行测试。这个流程就是对一个http请求的响应流程，正常运行的时候是通过springboot内嵌的tomcat来启动一个web server来监听http请求，然后响应该http请求。在测试的时候，如果也需要启动一个web server来监听请求，那么测试就更加困难了一些。还好spring-test为这个场景提供了便利，本文来了解一下它们的原理。
2025-07-14 22:42:46
312
原创 小架构step系列12：单元测试
测试的种类很多：单元测试、集成测试、系统测试等，程序员写代码进行测试的可以称为白盒测试，单元测试和集成测试都可以进行白盒测试，可以理解为单元测试是对某个类的某个方法进行测试，集成测试则是测试一连串的方法。测试代码也是代码，即使要求测试代码逻辑简单，但写单元测试代码也是要花时间的，维护也是要花时间的，所以在写测试代码上也要有些平衡。单元测试的颗粒度比较小，最接近方法的业务逻辑，应该详尽的测试；而集成测试牵扯的方法比较多，就比较复杂，就挑重点的地方做测试。本文先了解单元测试。
2025-07-12 17:40:36
863
原创 小架构step系列11：单元测试引入
在还没有写什么代码之前，就引入单元测试，是要强调单元测试的重要性。当一套代码的生命周期比较长的时候，单元测试更加重要。生命周期长的代码，不管是产品人员还是开发人员，可能都会换了一批又一批，维护才是成本的大头。后来的人缺乏这套代码的历史知识，改起来就会bug频出，质量堪忧。如果有单元测试代码，则每次的修改如果有问题，就能够通过单元测试代码暴露出来，这样改代码会比较让人放心。但单元测试代码是一项做了则太平无事看不出作用的事情，但不做则经常要灭火而追悔莫及的事情。
2025-07-11 16:39:31
1097
原创 小架构step系列10：日志热更新
日志主要是为定位问题使用的，日志一般分为5个级别：ERROR、WARN、INFO、DEBUG、TRACE，越往ERROR的方向问题越严重，越往TRACE的方向日志越详细、日志量越多，定位问题肯定是日志越详细越有帮助，但日志越详细其占用的磁盘空间越大，量过大也影响日志的检索性能，所以需要在中间做个平衡。生产环境偏向只打印ERROR和WARN级别的，最多到INFO级别，这样大部分问题都能够得到定位。
2025-07-10 18:23:28
283
原创 小架构step系列09：日志量控制
首先，要指定日志存储的位置，也就是存储在哪个目录下。 然后是一个日志文件不能过大，否则需要用的时候，想打开都比较困难，影响日志查看，需要设置一个单文件的最大量限制；既然一个文件不能过大，就必须对日志文件进行拆分，拆分后的文件名用什么格式命名；文件日志过多也不方便，在linux中一个目录下的文件个数也是有限的，需要对文件格式进行限制； 最后一个是对日志总量的限制，不管每个文件的大小和文件数量多少，总量不能超过指定的数量。2.2 原理2.2.1 根据文件名pattern初始化拆分文件的时间周期
2025-07-09 18:18:58
887
原创 小架构step系列08：logback.xml的配置
logback.xml配置文件的详细配置，很多地方都说得比较细，本文主要从几个重点来看一下原理，了解原理能够帮助确定哪些应该配置，以及如何配置。logback.xml是为打印日志服务的，打印的内容一般打印到控制台(Console)和文件(file)里，在生产环境中主要是打印到文件里，然后用扫描工具汇总到某个地方方便查询(如ELK)。打印的内容要符合一定的格式，提供足够的信息，方便进行日志查询和分析；
2025-07-08 21:29:54
663
原创 小架构step系列07：查找日志配置文件
日志这里采用logback，其为springboot默认的日志工具。其整体已经被springboot封装得比较好了，扔个配置文件到classpath里就能够使用。但在实际使用中，日志配置文件有可能需要进行改动，比如日志的打印级别，平时可能定的是WARN或者ERROR级别，如果出点问题，可能希望临时能够调整为INFO或者DEBUG，方便产生更加丰富的日志以定位问题。如果配置文件是放到classpath里，也就会被打包到jar包里，修改配置文件就需要重新打包、部署、启动等，很可能做不到只修改配置文件并生效。
2025-07-07 19:22:23
947
原创 小架构step系列06：编译配置
编写Java代码之后，需要经过编译、打包字节码、打包源码、生成文档之类的操作，这些操作里面的涉及到各种各样的工具和参数配置，这里仅介绍最基础的。建议这块能够简单就尽量简单，平时开发大部分的时间都会聚焦在开发业务功能上，这些编译打包相关的配置其实很少人会去搞懂它，经过一段时间人员的变换，可能里面的知识很容易就丢失掉了。如果配置过于复杂，做很多特殊的事情，那么如果出了问题或者需要调整，由于没多少人懂，那么维护起来就比较困难。所以总体的原则是简单到够用即可，能不用那些复杂的用法就尽量不用。
2025-07-06 17:15:40
472
原创 小架构step系列05：Springboot三种运行模式
前面搭建工程的例子，运行的是一个桌面程序，并不是一个Web程序，在这篇中我们把它改为Web程序，同时从启动角度看看它们的区别。
2025-07-05 16:45:27
981
原创 小架构step系列04：springboot提供的依赖
搭建的工程例子中，指定了spring-boot的spring-boot-starter-parent作为<parent>，然后在依赖中指定了spring-boot-starter依赖，里面没有指定版本，也没看到有指定核心Spring，却能够正常运行，这是如何工作的？
2025-07-04 21:40:12
782
原创 小架构step系列03：springboot与spring版本
可以看到1.x版本有65个，2.x有121个，3.x的目前有50多个，目前主要发展的是3.x，之前的版本基本已经锁定，大多不再更新甚至不维护了。1.x、2.x、3.x属于大版本更新，存在着不少不兼容的情况，更新一次并不容易，所以最好是使用3.x比较新一点的稳定版本。但一直不变动也是不行的，软件行业发展非常快，几年就大变样，说不定哪天就宣布停止服务了，客户听到停止服务就着急，不一定搞懂影响是什么，就强制必须升级。建工程的时候，涉及到SpringBoot的版本和JDK的版本，这两个版本是如何搭配的？
2025-07-03 16:32:42
794
原创 小架构step系列02：搭建工程
从上面可以看到，已经在<parent>节点选上了指定版本的springboot，在依赖<dependencies>节点中也加上了spring-boot-starter和spring-boot-starter-test，在<build>节点中指定了maven编译插件。建一个Java工程，编写pom.xml文件指定依赖，创建代码和配置文件的目录，建一个带main方法的启动文件，即可以完成最简单的工程搭建。对于一个简单的例子来说，上面三个可以选最新的版本都不受影响，一些详细的知识在后面的文章再详细介绍如何选择。
2025-07-02 16:38:13
625
原创 小架构step系列01：小架构初衷
自己实际经历的不少东西是历史沉淀下来的，历史的局限也在里面，要把它的一些局限更换掉，既需要对局限的内容深入了解，也要钻研一些新的知识，才能把这些局限更换掉，这需要花不少时间。在一家公司里，受限于人力有限和维护成本，从零建设架构的机会一般是很有限的，不太会每个项目都重头搞个不同的架构，这对公司的发展和维护是非常困难的。但也有个缺点，就是每次的迭代都是碎片化的，一个个知识就像一颗颗小珍珠一样散落到各个地方，总是感觉差一根绳子把这些零散的珍珠串接起来形成一个项链，也就是一个知识的体系。
2025-07-02 16:21:32
340
spring-framework-3.1.0.RELEASE-with-docs.zip
2012-01-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人