带过这么多届课程设计和毕业设计之后我越来越觉得“SSM 管理类系统”这个组合几乎是每个做Web开发的人都会遇到的标配。而商铺租赁管理系统恰好是这类项目中比较有代表性的一个业务场景够真实、功能边界够清晰、技术栈又非常经典用来练手或者直接作为毕设题目都非常合适。这篇文章我会从一个实际开发者的角度把基于SSM的商铺租赁管理系统从需求拆分、技术选型、数据库设计到核心代码落地的完整思路拿出来聊聊顺便把我踩过的坑和排查经验也一起整理进去。不管你是正要开始做这个课题的学生还是想快速理解SSM项目架构的初学者这篇文章都应该能帮你在动手前把方向理清楚少走弯路。1. 先说说为什么要做这个系统很多同学选题的时候容易选那种“看着高大上、实则无从下手”的题目比如智能推荐、分布式电商这种结果做着做着发现业务逻辑复杂到根本收不住最后变成了一个功能残缺的半成品。商铺租赁管理系统这类题目则完全不同它属于典型的“业务明确、链路完整、技术覆盖适中”的管理信息系统特别适合作为系统性学习Java Web开发的练手项目也适合用来展示你对业务和代码的综合把控能力。1.1 商铺租赁管理的真实痛点商铺租赁听起来就是“签合同、收租金”这么简单但真正管过或者调查过这个行业的人都知道这里面的琐碎程度远超想象。商场运营人员手里可能同时管着几十甚至上百个商铺每个商铺有独立的租户、押金、租期、租金标准、缴费周期和合同状态再加上转租、退租、续签这些变动如果全部靠Excel表格来管很容易出现几类问题合同到期时间记不清漏掉续签窗口期导致商铺空置损失。租金收缴进度靠手动追踪哪家拖了费、哪家押金抵扣了多少久了对不上账。合同和缴费记录分散在纸质文件或者不同人的电脑里复盘数据非常困难。租户信息和商铺信息变更频繁缺乏历史记录和流转痕迹。这个系统要解决的本质上就是“把分散在Excel、纸质合同和小本本里的信息统一收拢到一个在线平台上让每一步操作都有记录、有状态、可追踪”。这也是我经常和学生强调的一点——任何管理系统在需求分析阶段最重要的不是急着画界面而是搞清楚现有流程里到底“乱在哪里、痛在哪里”你的设计才有针对性。1.2 为什么选SSM这套组合SSM是Spring SpringMVC MyBatis的组合在Java Web领域火了很多年现在依然是大量企业级系统和新手教学项目的首选。原因很简单它的每一层都解决了特定问题组合起来正好够用。Spring负责对象管理和事务控制让整个应用的依赖关系变得清晰可控SpringMVC负责请求路由和参数绑定把浏览器发来的HTTP请求映射到对应的处理方法上MyBatis负责数据库操作用Mapper接口加XML的方式把SQL语句和Java代码解耦。三者在项目中各有定位单拎出来任何一个替代品比如用Spring Boot替换掉整个SSM、用JPA替换MyBatis也都能做系统但SSM“各管一段、分层清晰”的特点让学习者更容易理解Web开发的经典三层架构。再说实际的市场层面虽然Spring Boot现在已经非常流行但大量存量项目仍然是SSM架构很多企业的技术面试也还会问SSM相关的原理问题。把一个SSM项目吃透理解它背后依赖注入、AOP、ORM这些核心思想再切换到Spring Boot其实非常平滑。反过来如果你一上来就直接用Spring Boot的自动配置反而容易忽略掉底层装配的过程。这个项目的价值不在于“用最时髦的技术”而在于“把最经典的技术用扎实”。2. 整体设计与技术选型思路在真正动手写代码之前我习惯先把系统拆成几个层次去思考用户角色有哪些、核心业务流程是什么、数据如何流转、页面如何处理。这个阶段不需要写一行代码但直接决定了后续开发的顺利程度。2.1 SSM的核心分工与协作方式在做这个系统的时候官方一点的说法叫“前后端分离思想下的服务端分层架构”实际上就是从请求到响应的完整链路拆解。一次用户操作比如管理员在页面上点击“新增商铺”浏览器会发出一个HTTP请求SpringMVC的前端控制器DispatcherServlet先拦截到这个请求再通过HandlerMapping找到对应的Controller方法。Controller负责接收参数、调用Service层的方法Service层处理具体的业务逻辑比如校验商铺编号是否重复需要访问数据库时就调用Mapper接口——注意这里只是接口真正执行SQL的是MyBatis在启动时生成的代理实现。最后Controller把处理结果封装成ModelAndView或者JSON数据返回给页面前端渲染后展示给用户。如果简化成一句话页面负责展示和交互Controller只做调度不做业务Service专注业务规则Mapper专注SQL语句。这种分层的核心价值在于“职责单一”每一层都能独立测试和维护也方便团队成员分工协作。很多同学在写代码时喜欢把业务逻辑直接堆在Controller里虽然功能也能跑通但项目稍微变大之后就会出现大量重复代码改一个业务规则要到处找后面维护极其痛苦。2.2 数据库设计与ER思路商铺租赁管理系统的数据库设计是整个项目的地基我的习惯是先画ER图理清实体关系再落成表结构。核心实体大概有这些用户表管理员、运营人员账号商铺信息表商铺编号、位置、面积、状态租户信息表租户姓名、电话、证件号码租赁合同表关联商铺和租户记录租期、租金标准、押金付款记录表每笔租金收缴、押金收支消息通知表到期提醒、缴费提醒的发送记录实体之间的关系也比较清晰一个商铺可以有多条租赁合同历史租约当前租约一条合同对应一个租户一条合同会对应多条付款记录。这里要注意一个关键设计点——商铺和租户之间不是简单的一对一关系因为商铺会转租、退租后再租所以需要“合同表”作为中间纽带让两边的历史都能追溯。数据库设计过程中最容易踩的坑是“只想着满足当前页面展示忽略业务扩展”。比如“商铺状态”这个字段很多同学设计时给个int类型就完事但实际业务里商铺可能处于“未出租”“已出租”“已到期待续签”“维修中”等状态每个状态对应不同的可用操作这种状态流转在后面业务逻辑里就要做约束。如果你在设计时能把状态枚举清楚后面写代码就会顺畅很多。3. 核心功能模块与关键链路功能模块的划分直接决定系统能不能覆盖真实管理链路。我通常会把商铺租赁管理系统分成几个核心模块每个模块聚焦一类业务操作模块之间通过数据和状态串联。3.1 登录认证与权限控制管理类系统的第一步永远是身份认证。SSM项目里最常规的做法就是用拦截器实现登录校验定义一个HandlerInterceptor在preHandle方法里检查Session中是否存在登录用户如果没有就把请求重定向到登录页。权限控制的话可以给用户增加一个“角色”字段比如管理员和普通运营人员在拦截器里就可以判断哪些操作需要管理员权限。这里我提醒过很多次千万不要把登录校验只写在页面上。前端可以隐藏按钮但真正的安全性必须在服务端控制。拦截器的拦截范围也要注意register、login这些接口必须放行静态资源js、css、图片也要排除掉否则页面样式加载不出来排查半天才发现是拦截器把所有静态资源也拦了。3.2 商铺信息管理与合同管理商铺管理模块的核心是维护店铺的档案信息。除了基本的编号、名称、位置、面积我会建议加上“当前状态”和“关联合同”这两个维度。为什么因为运营人员打开商铺列表时最关心的不只是商铺的静态信息而是这个铺子现在是否在租、租给谁、租金是多少、什么时候到期。这样商铺列表和租赁合同模块之间就有了天然的数据联动。合同管理是整个系统里业务规则最复杂的模块。一份合同从创建到结束状态流转大概是待生效 → 生效中 → 到期/已终止。终止的场景又分为正常到期、提前退租、违约终止等。每种状态下都有不同的操作约束比如一个商铺在同一时间段只能存在一条“生效中”的合同。合同即将到期时可以发起续签续签本质是创建一条新合同。合同终止时必须结算剩余租金和押金退还逻辑。这块业务如果只做成“增删改查”那系统就会显得没有深度。我建议在需求设计阶段就把状态流转图画清楚用一张状态枚举表来约束每个状态允许执行的操作。这样不仅仅是为了应付答辩更是为了代码的可维护性。3.3 租金计算与到期提醒逻辑租金模块听起来就是“金额 单价 × 面积 × 月份数”但实际业务中往往会遇到押金抵扣、滞纳金、优惠减免、电费物业费合并收缴这些复杂情况。作为课程设计或毕设我建议至少把“应收金额、实收金额、未收金额”这几个字段分开存储不要每次临时计算因为一旦账单被修改过临时算出来的数字很难保证和页面之前展示的一致。保留每一笔缴费记录的实收金额和支付时间后续对账的时候有据可查。到期提醒功能是这个项目的一个加分项。最简单的实现方案就是维护一张定时任务表每天扫描合同表里距离结束日期小于N天的合同生成提醒记录插入消息表。如果用Spring自带的Scheduled注解就能实现只要在Spring配置里开启定时任务开关即可。提醒方式可以先做站内消息在系统首页显示待办提醒列表如果学有余力还能接入邮箱通知。这个功能的业务价值非常直观能很好地展示系统设计对真实业务的思考。3.4 数据统计与可视化看板管理系统的另一项刚需是统计功能。商铺出租率、租金收缴率、合同到期分布、每月的租金收入趋势这些都是运营方非常关注的指标。统计功能在SSM项目里的实现思路不复杂核心是SQL的聚合查询用GROUP BY按时间维度分组用SUM和COUNT统计对应的金额和数量。比如月租金收入统计SQL大致可以写成按年、按月分组汇总实收金额。图表展示方面可以在JSP页面中嵌入ECharts来画折线图和柱状图后端通过接口返回JSON数据前端用Ajax请求接口拿到数据后交给ECharts渲染。这里要注意一个细节——接口返回的JSON结构要设计得稳定尽量固定成“日期列表 金额列表”前端直接使用格式清晰还省去二次处理。很多同学在前后端联调时出现图表数据对不上往往就是JSON结构没有事先约定好。4. 核心业务代码落地与配置方案光梳理思路不落地代码等于纸上谈兵但直接贴一大段代码又容易让人看得一头雾水。这一章我把这个项目里最核心、也最值得参考的代码片段拆开来讲重点放在为什么这么写以及有哪些细节值得注意。4.1 数据库表结构定义的几个关键点先看几张核心表的定义以租赁合同表为例CREATE TABLE t_contract ( id INT PRIMARY KEY AUTO_INCREMENT, shop_id INT NOT NULL COMMENT 商铺ID, tenant_id INT NOT NULL COMMENT 租户ID, contract_no VARCHAR(50) NOT NULL COMMENT 合同编号, start_date DATE NOT NULL COMMENT 租期开始日, end_date DATE NOT NULL COMMENT 租期结束日, monthly_rent DECIMAL(10,2) NOT NULL COMMENT 月租金, deposit DECIMAL(10,2) NOT NULL COMMENT 押金, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待生效 1生效中 2已到期 3已终止, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL );几个容易踩坑的细节金额字段千万不要用float或doubleJava的二进制浮点数会有精度问题我强烈建议用DECIMAL比如DECIMAL(10,2)既能满足金额范围又不会出现0.10.2不等于0.3这种尴尬情况状态字段用TINYINT并加注释不要用字符串存“已生效”这种中文值数据库里存编码、页面上转义这是设计习惯问题日期类型用DATE还是DATETIME要区分清楚单纯日期用DATE需要精确到时分秒的就用DATETIME。我的建表习惯是每张表都带id自增主键和create_time、update_time再加一个逻辑删除字段deleted需要的时候用基础课程设计可加可不加。别小看这些基础字段后面做统计、排序、排查数据时就会体会到它们有多方便。4.2 Spring与MyBatis整合的核心配置很多同学在SSM整合阶段卡住一启动就报一堆Bean创建异常绝大多数问题都出在配置文件上。我通常的做法是在applicationContext.xml里配置组件扫描、数据源和事务管理器在spring-mvc.xml里单独扫描Controller层两者扫描范围要分开否则容易出现事务失效的问题。!-- applicationContext.xml -- context:component-scan base-packagecom.example.ssm context:exclude-filter typeannotation expressionorg.springframework.stereotype.Controller/ /context:component-scan bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName valuecom.mysql.cj.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/shop_rent?useSSLfalseamp;serverTimezoneAsia/Shanghai/ property nameusername valueroot/ property namepassword value123456/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.example.ssm.mapper/ /bean注意事项方面MySQL 8.0以上的驱动类名要写com.mysql.cj.jdbc.Driver并且必须配置serverTimezone否则会报时区异常mapperLocations的路径和实际放置Mapper XML的目录必须一致而且编译后要在classpath下面我见过很多次Mapper接口存在但XML找不到的情况Druid连接池的配置写起来简单但密码不要写明文在生产环境使用课程设计倒是无所谓不过这个安全习惯要养成。4.3 合同状态流转的Service层实现状态流转是业务核心写Service的时候最好先把动作定义清楚。比如合同续签操作本质上要做三件事把旧合同状态改为“已到期”或“已终止”创建一条新合同记录新租期、新租金如果涉及押金变动还要生成一条押金调整的付款记录。 Action类的逻辑用伪代码表示就是public void renewContract(Contract contract) { // 1. 校验旧合同状态必须是“生效中” Contract old contractMapper.selectById(contract.getId()); if (old null || old.getStatus() ! 1) { throw new BusinessException(当前合同状态不可续签); } // 2. 校验当前商铺没有其他生效中合同 int activeCount contractMapper.countActiveByShopId(old.getShopId()); if (activeCount 0) { throw new BusinessException(该商铺已有生效中的合同); } // 3. 更新旧合同状态 old.setStatus(2); // 到期 contractMapper.updateStatus(old); // 4. 插入新合同 contract.setStatus(0); contractMapper.insert(contract); // 5. 记录操作日志 logMapper.insert(...); }这段逻辑里最关键的就是第2步校验。为什么因为“一个商铺同一时间只能有一个生效合同”属于业务规则不是数据库能自动约束的除非你用排除索引但那样会显著增加复杂度所以必须放在Service层用代码保证。这也是Service层存在的意义——承载业务规则。很多初学者用一个Mapper搞定所有事不是不行但后续每次改动都要在Controller里翻来翻去改一个逻辑就要改动页面、Controller、Mapper三处相关代码非常容易漏改。4.4 租金计算时段的工具方法租金计算中有一个让不少人头痛的点月中起租或退租时非整月的租金怎么算比如租户从某月15号开始租当月租金到底是按整月算还是按天折算不同项目有不同的规则我这里提供一个常用的按月折算方式public static BigDecimal calcMonthlyRent(BigDecimal monthlyRent, LocalDate start, LocalDate end) { YearMonth ymStart YearMonth.from(start); YearMonth ymEnd YearMonth.from(end); // 同一个自然月内按天占比计算 if (ymStart.equals(ymEnd)) { int days end.getDayOfMonth() - start.getDayOfMonth() 1; return monthlyRent .multiply(BigDecimal.valueOf(days)) .divide(BigDecimal.valueOf(ymStart.lengthOfMonth()), 2, RoundingMode.HALF_UP); } // 跨月场景第一个月按比例中间月份整月计算最后一个月按比例 // 这里为简化就按首月比例尾月比例整月数来计算 BigDecimal firstMonth monthlyRent .multiply(BigDecimal.valueOf(ymStart.lengthOfMonth() - start.getDayOfMonth() 1)) .divide(BigDecimal.valueOf(ymStart.lengthOfMonth()), 2, RoundingMode.HALF_UP); BigDecimal lastMonth monthlyRent .multiply(BigDecimal.valueOf(end.getDayOfMonth())) .divide(BigDecimal.valueOf(ymEnd.lengthOfMonth()), 2, RoundingMode.HALF_UP); BigDecimal fullMonths monthlyRent.multiply(BigDecimal.valueOf( ChronoUnit.MONTHS.between(ymStart, ymEnd) - 1)); return firstMonth.add(fullMonths).add(lastMonth); }这段代码的价值在于把“非整月如何算租”这种边界情况定义清楚了。真实业务中一定会有这种不规律时间段的计费需求提前写好工具方法能省掉大量重复劳动。JJ注意分情况讨论方法里要写清楚注释否则三个月后你自己回来看可能也想不起来当初为什么这么写。5. 开发中高频踩坑与排查实录这部分我单独拿出来写是因为在实际指导项目过程中几乎没有哪个项目能一路顺畅写完。下面这些问题都是我和学生们真实遇到过的频率非常高如果提前知道能省下好几个晚上的排查时间。5.1 日期类型导致的JSON格式化问题现象是前端页面显示的日期变成了“2025-05-01T00:00:00”这种带T的格式非常影响阅读。原因是后端返回的日期类型默认序列化格式。解决方案是在项目的Jackson配置中统一指定日期格式或者在日期字段上使用JsonFormat注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime createTime;同时要注意类字段如果用的是java.util.Date建议改成java.time.LocalDate/LocalDateTime。MyBatis在3.5.0以上版本对Java 8时间类型的支持已经很好不需要额外处理但数据库驱动版本太老也会出现LocalDateTime映射异常这个坑通常是数据库驱动版本不兼容导致的升级驱动一般能解决。5.2 一商铺多合同并发冲突我参与过的一个模拟项目中测试人员连续点击“签约”按钮两次结果同一个商铺生成了两条生效中的合同。原因就是合同状态校验和插入操作不是原子的两个请求同时通过了“没有生效中合同”的校验然后各自插入了一条记录。解决这个问题有两种思路一是给商铺ID加数据库层唯一约束比如给shop_id和status生成唯一索引只允许一个生效中记录但这样可能需要冗余字段二是在Service层加同步锁比如使用synchronized关键字或者基于Redis的分布式锁。对于单体SSM项目最简单可靠的方案其实是数据库的“悲观锁”或“唯一索引”。我在实际项目里推荐的做法是数据库加唯一约束兜底业务层加状态校验双保险。这个经验在技术上叫“并发控制”在业务上叫“防止重复签约”面试时能讲出来会加分。5.3 MyBatis的模糊查询和动态SQL细节Mapper文件中写模糊查询时最常见的错误是直接拼接字符串导致SQL注入风险。正确写法是使用CONCAT函数select idselectByName resultTypecom.example.ssm.entity.Tenant SELECT * FROM t_tenant WHERE name LIKE CONCAT(%, #{keyword}, %) /select动态SQL方面 和 标签的配合可以让我们省去拼接WHERE和AND的烦恼。还有一个细节如果实体类的属性名和数据库字段名不一致要么给数据库字段起别名要么在mybatis-config.xml中开启驼峰映射配置setting namemapUnderscoreToCamelCase valuetrue/这个配置能自动把数据库的create_time映射成Java对象的createTime不需要每个字段都手写resultMap简洁非常多。5.4 开发环境跨端口联调与浏览器兼容我见过很多学生项目里前端页面写的是完整路径比如http://localhost:8080/login这样做在开发环境没问题但部署到服务器后所有路径都要改。更合理的做法是所有请求路径写成相对路径比如login、/admin/dashboard这类非完整URL这样前后端不管部署在什么位置都能正确跳转。关于跨域如果页面和后端接口不在同一个端口比如前端用Vue开发服务器端口是8081后端8080就需要在后端配置CORS跨域支持。SSM项目里最简单的方案是写一个过滤器类添加响应头Access-Control-Allow-Origin。不过如果直接用JSP做页面后端和页面在同一个应用里通常不需要考虑跨域问题这个问题更多出现在前后端分离的改造场景。浏览器兼容方面如果用了一些比较新的ES6语法或者CSS特性记得检查目标浏览器是否支持特别是JSP页面在老版本IE环境下的兼容性。5.5 事务失效问题排查这个坑在SSM项目里特别隐蔽。表现是Service方法里前一步插入了数据后一步抛出异常但前一步的数据并没有回滚数据库里残留了脏数据。排查思路先确认Spring事务管理的配置是否正常看事务管理器是否注入到了数据源再确认Service方法是否被正确扫描Transactional注解是否写在了类或方法上最后还要确认你在applicationContext.xml中是否扫描到Service层类。如果事务没有生效多半是扫描配置出了问题比如Service和Mapper的包扫描范围不对导致Spring没有创建代理对象。还有一个很容易忽略的小问题——事务方法是public修饰的吗如果写成private或者包内调用同一个类中方法调用事务方法Spring默认基于JDK动态代理的机制是拦截不到的事务就会失效这个知识点虽然基础但经常出现在“为什么我加了Transactional还是不回滚”的问题里。6. 项目还能怎么扩展和深化如果你做的是毕设或者求职项目这个系统在完成了基础功能之后还有几个方向可以继续深化能让项目的技术含量高一个台阶。6.1 引入Shiro或Spring Security强化权限管理之前说的权限控制用拦截器实现其实是一种比较“手工化”的方案。如果想让项目更规范可以引入Shiro或Spring Security来做认证和授权管理。这样一来角色权限、URL级别的访问控制、会话管理都可以交给安全框架处理项目本身对权限策略的描述也清晰很多。虽然学习和配置成本会高一些但对SSM项目来说是一个很自然的进阶方向。6.2 集成消息中间件或异步任务到期提醒如果只靠定时任务扫描数据库在数据量小的时候没问题但如果合同数量很大频繁全表扫描会浪费资源。可以优化策略把提醒任务拆成两阶段定时任务只负责查询未来N天内到期的合同然后发送异步消息再配合一个独立的短信或邮件接口做通知。如果项目里引入了RabbitMQ或Redis的延迟队列就更有技术亮点了。当然对入门项目来说这部分属于加分项量力而行。6.3 数据权限和操作日志真实商铺租赁系统里一个运营平台不可能只有两个固定角色通常是大区经理、招商专员、财务专员这些不同角色分别管理不同范围内的商铺。这时候就需要数据权限——比如招商专员只能看到自己名下负责的商铺。实现方式可以在商铺表中增加owner_id字段在查询时加数据权限过滤。这个功能展示了系统设计者对业务的理解深度课程设计做到这步已经是优秀水平。操作日志方面可以建立一个日志表记录关键操作的“谁在什么时间对什么数据执行了什么操作”尤其是合同状态变更、租金收款这类敏感操作。这不仅仅是答辩时说的高大上功能在实际项目里真的是刚需。个人实操体会如果让我给准备做这个题目的同学一个最重要的建议那就是别急着追求技术栈的新奇先把商铺租赁的业务链条吃透。SSM这套技术组合虽然听起来不是最新的但正因为它的每个组件都足够经典你才能在项目里看到“分层架构、依赖注入、ORM映射、事务管理、定时任务”这些后端开发的核心概念是如何落地的。做的过程中遇到的每一个报错、每一种业务约束和并发冲突都是在真实工作里会遇到的场景解决掉它们胜过背十遍面试题。如果还有余力建议把项目从JSP改成前后端分离试试比如前端用Vue后端只提供JSON接口。你会发现Controller这部分的工作方式会发生巨大变化对API设计、跨域、异常处理的体会会更深。这个课题的容错率其实很高从一开始就踏踏实实把一个模块做完整比把所有模块都做成半成品强得多。最后祝你顺利做出来有什么问题欢迎在实际开发中多调试、多验证动手才是最快的成长路径。