做商铺租赁管理系统这个选题之前我其实犹豫过——市面上类似的某某管理系统太多了大多数人的第一反应都是这不就是一个增删改查吗但真正接手之后才发现商铺租赁的业务逻辑远比表面看到的复杂同一个商铺不能同时租给两家租金要按不同的结算周期生成账单合同到期前需要提醒运营方决定续租还是回收还有押金、违约金、物业费这些杂七杂八的费用要处理。这篇文章我会从业务建模、数据库设计到核心功能落地把我实际开发这套系统时的完整思路、设计取舍和踩坑过程都写出来。如果你想做SSM相关的毕业设计或者小团队要搭建一套可用的商铺租赁管理工具这篇应该能帮你省不少时间。1. 业务建模先行商铺租赁到底在管什么1.1 从一张Excel表开始的业务痛点我最初接触这个项目是帮一个做商业运营的朋友梳理需求。他们当时管理几十个商铺的租赁情况用的是一张巨大的Excel表里面有铺位编号、租户姓名、合同起止日期、租金单价、押金金额、有无欠费……十几个列。看起来信息都有但实际用起来全是问题某个铺位合同快到期了没人记得去提醒铺子空置了大半个月才知道。同一个铺位在系统外被口头承诺给了两个意向客户最后合同只能签一个另一个客户觉得被坑了。租金有的按季度收有的按半年收还有的约定递增比例算账全靠财务手动算偶尔漏算一笔。想统计一下当前的整体空置率、租金收缴率得临时做透视表折腾老半天。这些痛点落到系统里对应的就是几个核心需求铺位档案管理、租户/客户管理、合同全生命周期管理、租金账单管理、到期预警和基础报表统计。所以我在设计系统时没有一上来就写代码而是先花了两天把业务链路梳理清楚。1.2 角色权限三类后台角色就够了很多管理系统喜欢把权限搞得很复杂老板、经理、主管、专员各一套。但商铺租赁这个场景实际使用角色就三类管理员维护商铺档案、租户档案、系统账号看全局统计报表。相当于系统维护者决策者。运营/招商人员登记合同、办理退租、处理合同变更。日常操作最频繁的角色。财务人员生成租金账单、登记收款记录、查询欠费情况。这三类角色对应到SSM项目里就是一个基于RBAC基于角色的访问控制的简单权限模型。用户表sys_user、角色表sys_role、权限表sys_permission加上用户-角色、角色-权限两张关联表。登录后把权限标识放进sessionSpringMVC用拦截器做URL级别的权限校验。比如/admin/开头的URL只有管理员能访问/finance/只有财务角色能访问。这个设计不复杂但能撑起整个系统的访问安全骨架。1.3 核心状态机商铺与合同的三个状态流转这是被很多人忽略、但恰恰是系统设计最关键的部分。商铺和合同都有各自的状态而且二者状态是需要联动变化的。商铺的状态相对简单我设计了三种空置AVAILABLE可以对外招租。已出租RENTED存在一份生效中的合同。锁定LOCKED预留、装修期或纠纷处理中暂不能出租。合同的状态流转稍微复杂一些待生效PENDING已签约但还没到起租日期。履行中ACTIVE当前处于合同期内。已到期EXPIRED合同时间到了没有续租。已终止TERMINATED中途违约、协商解约等提前结束。已续租RENEWED原合同被新合同接续历史合同标记为已续租。这两个状态不是孤立的。比如当一份合同变为ACTIVE关联的商铺状态必须同步改为RENTED当合同变为EXPIRED或TERMINATED商铺恢复为AVAILABLE。这个联动最好不要靠业务代码到处判断而是抽成一个合同状态变更服务所有状态变更都走这个服务由它统一去更新商铺状态并记录操作日志。后面我会再详细提到这个设计。2. SSM框架选择的背后逻辑与工程分层设计2.1 为什么这个项目适合SSM而不是Spring Boot现在聊到新项目几乎默认就是Spring Boot。但我在这套系统上选择Spring SpringMVC MyBatisSSM并不是因为不会Spring Boot而是有实际的考虑第一SSM的配置是显式的适合理解Web应用的工作原理。Spring Boot大量使用自动配置很多细节被约定大于配置掩盖了。但对于要拿来做毕设或者作为学习项目的场景SSM能让你清楚地看到Spring容器怎么启动、SpringMVC的DispatcherServlet怎么拦截请求、MyBatis的SqlSessionFactory怎么整合进Spring IoC。这些理解其实比会用Spring Boot更重要。第二部署环境对技术栈有约束。我接触到的部分中小型团队服务器还是传统的Tomcat JDK 8项目打包成WAR包部署团队更熟悉XML配置和传统分层结构。SSM在这种环境下非常成熟稳定出了问题也好排查。第三这个项目本身的业务复杂度SSM完全够用。商铺租赁管理系统没有高并发、没有分布式、没有微服务需求核心就是业务逻辑的正确性和数据的一致性。用一个轻量、可控、文档资料丰富的框架组合是性价比最高的选择。当然如果你是个人学习我依然建议在掌握了SSM之后去对比一下Spring Boot的实现方式能更深刻地理解框架自动配置的背后逻辑。2.2 工程分层Controller、Service、Mapper各自的责任整个项目按经典的三层架构组织包结构如下src/main/java ├── com.rent.controller // SpringMVC控制器层 ├── com.rent.service // 业务层接口 ├── com.rent.service.impl // 业务层实现 ├── com.rent.dao // MyBatis数据访问层接口 ├── com.rent.entity // 实体类PO ├── com.rent.dto // 数据传输对象用于页面渲染和接口入参 ├── com.rent.common // 公共类常量、分页类、统一返回结果、异常处理 ├── com.rent.interceptor // 登录、权限拦截器 └── com.rent.util // 工具类日期处理、金额处理等这套分层的边界要拎清楚Controller层只做参数接收、参数简单校验、调用Service、封装返回结果。不要在Controller里写业务逻辑更不要直接操作数据库。Service层承担核心业务规则比如合同时间冲突校验、租金计算、状态流转。一个Service方法对应一个完整的业务动作保证事务边界清晰。Mapper层只负责SQL和数据映射。复杂的多表联查可以在Mapper XML里写好但尽量不在XML里写业务判断。我见过很多同学把业务逻辑直接堆在Controller里一个方法几百行最后项目都写不下去了。三层各司其职这个规矩一开始就要立住。2.3 前端方案JSP Bootstrap 的务实选择前端我用了JSP Bootstrap jQuery。有些人会觉得这技术栈有点老但对这个项目来说是务实的SSM项目前后端分离的成本较高用JSP可以直接复用Service层返回的Model数据服务端渲染简单直接。Bootstrap能快速搞定后台管理界面的布局和组件不需要花时间折腾复杂的前端工程化。jQuery做AJAX请求交互处理表单提交、局部刷新已经足够。页面骨架就是一个经典的左侧菜单 顶部导航 右侧内容区的后台布局。每个功能模块的页面风格保持统一表格用Bootstrap的table组件表单做基本的前端校验再用Layer组件弹提示框。这套组合开发效率非常高对于管理类系统来说完全够用。实际开发中我封装了一个简单的分页工具类后端统一接收页码pageNum和每页大小pageSize返回分页数据和总条数前端通过jQuery把表格数据渲染出来。MyBatis分页用的是PageHelper插件一行配置就能生效比手写LIMIT方便很多。3. 数据库建模的核心商铺、客户、合同、租金四张表的关联设计3.1 商铺信息表先解决铺位档案的规范化商铺表的核心字段我设计了这些字段名类型说明shop_idint主键自增shop_codevarchar(20)铺位编号如A-101业务上需要唯一shop_namevarchar(100)铺位名称/门牌areadecimal(10,2)建筑面积平方米floorint所在楼层shop_typevarchar(20)铺位类型餐饮/零售/服务等unit_pricedecimal(10,2)基础租金单价元/月deposit_standarddecimal(10,2)押金标准比如押三付一中的押三对应金额statusvarchar(20)状态AVAILABLE/RENTED/LOCKEDproperty_feedecimal(10,2)每月物业费可单独计费descriptionvarchar(500)备注create_timedatetime创建时间这里有几个细节要注意。unit_price我用的是每平方米/月这种单价因为很多商铺的租金是随面积浮动的租约中会写明单价×面积月租金。但实际业务中也有人只按一个固定总额出租所以我额外设计了一个字段rent_fixed标记是按单价计算还是按固定金额计算避免一刀切。deposit_standard单独存不是为了展示是为了后面算违约扣款和退租结算时有依据。3.2 客户表租户信息做到可复用客户表我用了customer这个名字而不是tenant。因为一个客户可能先后租过多个铺位也可能同时租好几个铺位它本质上是租户档案而非某次租赁绑定关系。字段包括客户名称、证件类型、证件号码、电话、联系人、公司/个人类型、通讯地址、紧急联系人等。身份证号在界面上做了脱敏显示保留前四后四数据库里正常存储权限上限制为管理员和财务可见。这里的设计考虑是客户信息属于个人敏感信息不能让所有角色都随意查看完整证件号。3.3 合同表状态与关联是核心合同表是整个系统的核心每个字段都有业务含义字段名类型说明contract_idint主键contract_novarchar(32)合同编号如HT202506001shop_idint关联商铺表customer_idint关联客户表start_datedate合同开始日期end_datedate合同结束日期rent_typevarchar(20)计租方式MONTHLY/QUARTERLY/YEARLYupfront_monthsint首次预交月数押几付几中的付几deposit_monthsint押金月数monthly_rentdecimal(12,2)月租金签署价deposit_amountdecimal(12,2)实际押金金额statusvarchar(20)PENDING/ACTIVE/EXPIRED/TERMINATED/RENEWEDsign_datedate签约日期remarkvarchar(500)备注create_timedatetime创建时间合同表与商铺表是多对一与客户表也是多对一。也就是说一个商铺可以有多个历史合同一个客户也可以有多个合同。查询时经常需要用商铺或客户反查其当前生效合同所以在shop_id和customer_id上都必须建索引。start_date和end_date是时间范围条件查询的常用字段同样建议加索引。3.4 租金流水表把费用往来全部落账租金流水表记录每一笔应收或实收字段名类型说明payment_idint主键contract_idint关联合同shop_idint冗余商铺便于统计按铺位的欠缴情况period_startdate账单周期开始period_enddate账单周期结束amountdecimal(12,2)应收金额paid_amountdecimal(12,2)实收金额statusvarchar(20)UNPAID/PARTIAL/PAIDdue_datedate应交日期pay_timedatetime实际交款时间pay_methodvarchar(20)转账/现金/刷卡operatorvarchar(50)操作员租金流水和合同之间是一对多的关系。每次生成租金账单时会根据合同周期自动拆分成多笔流水。shop_id冗余在这里是因为统计某个铺位欠了多少钱是高频查询避免每次都要通过合同反查商铺。冗余字段会带来数据一致性维护成本但这种程度的冗余在业务报表场景下收益远大于成本。3.5 时间字段与状态字段的约束关系建表和开发过程中有个约束很容易被忽略合同时间内不允许交叉、状态和数据必须联动。数据库层面能做的约束有限但我用了几条SQL约束保证数据基本合理性end_date必须大于start_dateMySQL 8.0以上支持CHECK约束5.7及以前需要在应用层保证。monthly_rent和deposit_amount必须大于0。商铺表状态字段用VARCHAR存储可读性更好的枚举值而不是数字这样排查数据时一眼能看懂。状态联动比如合同变成终止商铺自动改空置不适合放在数据库触发器里因为涉及后续的押金结算等一连串业务操作。这个逻辑我会放在Service层的事务中统一处理。4. 核心功能落地合同登记、租金计算与到期预警4.1 合同登记不只是插入一条记录那么简单很多人写合同登记的代码就是insert into contract然后完事。但真实的合同登记是一连串动作前端提交合同信息。后端校验商铺是否存在、客户是否存在、合同时间是否合法。校验商铺在合同起止时间内没有其他生效合同——这是防止一铺多租的关键。根据押金标准和月租金计算押金金额。生成合同编号。插入合同记录状态为待生效或履行中。如果合同立即生效则同步把商铺状态改为已出租。生成第一期的租金账单。记录操作日志。串起来就是Transactional(rollbackFor Exception.class) public Contract saveContract(ContractDTO dto) { // 1. 校验商铺与客户存在 Shop shop shopDao.selectById(dto.getShopId()); Customer customer customerDao.selectById(dto.getCustomerId()); if (shop null || customer null) { throw new BusinessException(商铺或客户不存在); } if (dto.getEndDate().before(dto.getStartDate())) { throw new BusinessException(合同结束日期必须晚于开始日期); } // 2. 时间冲突校验 int conflict contractDao.countConflictingContracts(shop.getId(), dto.getStartDate(), dto.getEndDate()); if (conflict 0) { throw new BusinessException(该商铺在所选时间段内已有合同不能重复出租); } // 3. 组装合同并插入 Contract contract buildContract(dto); contract.setContractNo(generateContractNo()); contractDao.insert(contract); // 4. 自动生成第一期租金账单 generateRentPayments(contract); // 5. 变更商铺状态 shopDao.updateStatus(contract.getShopId(), RENTED); return contract; }事务注解Transactional放在Service实现类方法上保证以上任何一步失败已经插入的数据全部回滚。这是此类业务的基本功不能省。这里要特别说明时间冲突的SQL写法。冲突的条件是新合同的开始时间 小于等于 已生效合同的结束时间 且 新合同的结束时间 大于等于 已生效合同的开始时间。翻译成SQLselect idcountConflictingContracts resultTypeint SELECT COUNT(*) FROM lease_contract WHERE shop_id #{shopId} AND status IN (PENDING, ACTIVE) AND #{startDate} lt; end_date AND #{endDate} gt; start_date /select注意XML里小于号要转义成lt;否则MyBatis解析XML会报错。这个坑我踩过后面专门再讲。4.2 租金计算按周期拆分账单的完整逻辑租金账单的生成是这套系统里算法性最强的一块。租赁合同常见的有按月付、按季付、按半年付、按年付还有递增租金约定。我的实现思路是合同表里存rent_type计费周期类型。根据计费周期把整个合同期拆成N个账单周期。每个周期生成一个应收账单金额 月租金 × 周期月数。首期账单可能在签约时立即生成后续账单按周期提前生成。拆分期数的代码大致是这样public ListRentPayment buildPaymentPlan(Contract c) { ListRentPayment list new ArrayList(); LocalDate cursor c.getStartDate().toLocalDate(); LocalDate end c.getEndDate().toLocalDate(); int cycleMonths getCycleMonths(c.getRentType()); int seq 1; while (cursor.isBefore(end) || cursor.isEqual(end)) { LocalDate periodEnd cursor.plusMonths(cycleMonths).minusDays(1); if (periodEnd.isAfter(end)) { periodEnd end; } RentPayment rp new RentPayment(); rp.setContractId(c.getId()); rp.setShopId(c.getShopId()); rp.setPeriodStart(cursor); rp.setPeriodEnd(periodEnd); rp.setAmount(BigDecimal.valueOf(c.getMonthlyRent()) .multiply(BigDecimal.valueOf( ChronoUnit.MONTHS.between(cursor, periodEnd) 1))); rp.setDueDate(cursor); rp.setStatus(UNPAID); list.add(rp); cursor periodEnd.plusDays(1); seq; } return list; }这段逻辑里有几个业务约定比如账单的应交日期我默认设为每个周期的起始日意味着当期一开始就要交清最后一段不足一个完整周期时按实际天数折算月数实际项目中可以约定为不足一个月按一个月计算或按天折算这个要看合同条款来定不要自己瞎定。金额字段一律用BigDecimal绝对不能用double。double在涉及小数点运算的时候会有精度问题比如0.10.2得到0.30000000000000004在财务系统里这是不可接受的低级错误。4.3 到期预警一个定时任务驱动状态流转到期提醒的设计很简单但很实用。我的方案是维护一张提醒配置表或者在系统参数表里存提前N天提醒。然后每天跑一个Spring定时任务用Spring自带的Scheduled注解配置cron表达式扫描未来30天内到期且状态为ACTIVE的合同把提醒记录写入提醒表运营人员登录后首页直接展示。Scheduled(cron 0 30 2 * * ?) // 每天凌晨2:30执行 public void checkExpiringContracts() { Date deadline DateUtils.addDays(new Date(), 30); ListContract expiringList contractDao.selectActiveContractsEndBefore(deadline); for (Contract c : expiringList) { reminderDao.insert(new Reminder(c.getContractId(), 合同将于 c.getEndDate() 到期请及时进行续租或收回处理)); } }这个定时任务建议配合一个last_check_date表记录上次执行日期防止重复插入提醒记录。同时合同到期支持两种流转方式续租原状态改为RENEWED创建新合同和到期收回状态改为EXPIRED商铺状态改AVAILABLE。这两种操作都放到合同状态变更服务里统一处理避免不同开发各自改导致状态乱掉。4.4 报表统计站在运营视角看数据系统除了日常操作还必须给管理层提供基础报表。我实现了三个比较核心的统计商铺出租率已出租商铺数 / 总商铺数。租金收缴率实收金额 / 应收金额按时间段。到期合同列表按到期时间倒序展示未来三个月到期合同支持按商铺筛选。这些统计在首页Dashboard上展示通过一个聚合SQL查询即可完成。比如某段时间的收缴率SELECT COALESCE(SUM(CASE WHEN status IN (PAID,PARTIAL) THEN paid_amount END), 0) / COALESCE(SUM(amount), 0) AS collection_rate FROM rent_payment WHERE due_date BETWEEN #{startDate} AND #{endDate}这种做法简单直接。如果后期数据量大可以考虑用定时任务把统计结果物化到一张报表表中但数据量没到几十万条之前不需要过度设计。5. 实测排错时间冲突、状态流转与金额精度三个绕不开的坑5.1 MyBatis XML中的小于号转义错误开发时我往合同冲突检测的SQL里直接写了#{startDate} end_date结果项目启动直接报XML解析异常检查才发现是导致的。MyBatis的XML映射文件本质是XML文档小于号在XML中会被当成标签起始符。解决方式有两种转义写法lt;和gt;用CDATA包裹![CDATA[ #{startDate} end_date ]]我最终把涉及比较运算的SQL片段统一用CDATA包起来代码可读性更好不用一个一个去记转义字符。5.2 合同时间冲突检测的边界条件这个坑最隐蔽。第一次上线测试时运营反馈为什么隔壁铺位的时间冲突检测把同铺位的合同也拦了查代码发现我在SQL里只判断了店铺ID和时间重叠但忘了排除当前这条合同自己。更麻烦的是边界条件新合同的开始日期恰好等于旧合同的结束日期这种无缝衔接在业务上是允许的——上一家最后一天退租下一家第二天进场中间没有对商铺产生占用冲突。但如果时间判断条件写错了就会把这种合法场景判定为冲突。最终我把冲突条件明确为存在生效合同且新合同开始时间小于旧合同结束时间、新合同结束时间大于旧合同开始时间。等于的情况不冲突这是经过和运营确认后的业务规则。写这种时间重叠判断时一定要先把边界条件列清楚再写SQL不要凭感觉。5.3 合同状态和商铺状态不同步导致的数据脏数据有一段时间运营反馈商铺明明显示已出租但点进去看不到任何生效合同。排查后发现有几个合同记录是从后台数据库直接改了状态字段为了应付测试绕过了Service层的状态变更逻辑导致商铺状态没有联动更新。这暴露了两个问题任何状态变更必须走统一的服务方法不能直接改库。需要在商铺列表查询时做一个自愈逻辑如果商铺状态为已出租但查不到生效合同自动把状态改回空置。我在状态变更服务里增加了统一的枚举校验所有状态修改入口都调同一个方法changeContractStatus(contractId, targetStatus, operatorId)方法内部维护一张状态流转规则表不满足流转规则的直接抛异常。比如从PENDING可以直接到ACTIVE但不能从PENDING直接跳到TERMINATED除非有特殊原因标记。代码量不大但能有效避免状态混乱。5.4 金额精度问题BigDecimal使用不当照样出错关于金额用BigDecimal这个建议很多人都知道但用的过程中还是有几个细节容易出错BigDecimal的构造方法new BigDecimal(0.1)会得到一个近似值0.1000000000000000055511151231257827。必须用BigDecimal.valueOf(0.1)或者new BigDecimal(0.1)。除法要指定精度和舍入方式比如计算每日租金BigDecimal.valueOf(monthlyRent).divide(BigDecimal.valueOf(days), 2, RoundingMode.HALF_UP)否则除不尽时会抛ArithmeticException。金额比较用compareToa.compareTo(b) 0判断相等而不是a.equals(b)因为equals会要求精度完全一致。我在租金计算的工具类里统一封装了金额运算方法全项目所有金额计算都走这个工具类禁止到处直接new BigDecimal。5.5 并发问题同一商铺被同时下单这个场景在真实业务里也发生过两个运营人员同时登录系统同时操作同一个空置商铺都提交了合同结果数据库里出现了两条生效合同。单机部署的SSM系统时间冲突检测的SQL虽然逻辑正确但由于两个请求是并发的各自都先查没有冲突再插入于是都成功了。解决方式是在商铺表上加一个乐观锁版本号version字段。合同保存时先执行UPDATE shop SET status RENTED, version version 1 WHERE shop_id #{shopId} AND status AVAILABLE如果更新影响的行数为0说明商铺已经被其他人改过了直接抛出商铺状态已变更请刷新后重试。这个方案简单有效也不需要引入分布式锁对于这种体量的项目是成本最低的并发保护方案。6. 事务边界与权限安全的几个设计细节6.1 事务边界怎么划才算对SSM项目中事务用Transactional注解可以解决问题但边界必须想清楚。我的经验是以下操作必须放在同一个事务里创建合同同时生成账单、更新商铺状态。合同终止同时结算押金、生成退款单。批量生成账单时部分失败必须全部回滚否则会出现账单半截的情况。但不要把耗时操作、外部调用比如短信通知、邮件提醒放到事务里面否则事务长时间持锁数据库连接容易被占满。我的处理是核心数据操作一个事务事务提交后再异步执行通知动作。这样既保证数据一致又不会因为外部服务慢拖垮整个请求。6.2 登录安全与SQL注入防护这是老生常谈但商铺租赁系统里客户和合同数据很敏感还是要有底线意识密码存储使用BCrypt加密登录比对用BCrypt的matches方法不允许明文密码入库。登录拦截器SpringMVC拦截器拦截所有页面的访问未登录跳转到登录页管理员URL再叠加角色校验。SQL注入MyBatis的#{}参数预编译天然防注入但注意不要图方便写${}拼接特别是排序字段和动态表名这种无法预编译的场景必须做白名单校验。我可以提供一个简单的排序字段白名单工具前端传的排序字段必须匹配枚举或正则否则使用默认排序从源头杜绝${}注入风险。6.3 界面上的小细节下拉联动与操作二次确认最后说几个提升使用体验的小细节这些不写也不会有人怪你但写了使用者会明显觉得系统像个正经系统商铺下拉框联动显示面积、租金单价、当前状态。运营人员选铺位时不用另外开窗口查。合同表单里选择客户时支持按手机号快速搜索因为很多运营根本记不住客户全名但能记住电话。终止合同、删除合同这类不可逆操作必须有确认弹窗并且在页面显眼位置提示影响范围比如终止后将释放商铺并自动退租。这类保护性确认能避免不少误操作。7. 这套系统的后续扩展思路SSM版本的商铺租赁系统做完之后整个技术骨架和业务模型是完全可以向上演进的。我自己的体会是项目做完之后不妨想一想这几个方向升级到Spring Boot数据表和业务逻辑基本不用动把XML配置迁移成注解 application.yml部署方式从WAR变成JARService层和Mapper层可以完全复用。增加小程序端租户可以通过手机查看租金账单、缴费记录、合同信息后端把核心接口用RESTful风格暴露出来前端对接小程序。这个扩展能最大程度提升租户的使用体验。财务报表增强除了收缴率可以增加账单逾期账单提醒模块对超过应交日期未付款的账单自动计算滞纳金并推送提醒给运营人员减少人工催缴成本。对接电子签章合同在线上完成签署签约后自动生成合同编号并归档难点在于签章服务对接和合同文件存储但做出来之后整个招商流程的效率会明显提升。如果只是做毕设完成前四个模块已经足够体现工作量如果是真实落地到商业运营场景至少要把权限设计、数据审计日志和备份方案补完整。根据团队的交付期限和运维能力分阶段推进是比较务实的路径。系统开发到最后真正让我觉得有价值的其实不是技术本身而是把运营团队原本那套Excel流程梳理成了清晰的数据模型和状态机。商铺租赁这种业务核心规则并不复杂但它要求开发人员先懂业务再写代码。如果你现在正准备开这样一个项目我建议你花一周时间和真实的业务方聊一聊把他们的痛点列成清单再动手设计表结构——这一步省下来的返工时间远比你想的要多。
