简介本资源是一套面向高校计算机专业本科生毕业设计与课程实训的完整供应链管理系统实现方案基于JavaEE平台采用SSHStruts2SpringHibernate经典三层架构结合MySQL数据库构建百货中心级业务场景。系统覆盖采购管理、销售管理、库存监控、供应商协作及用户权限控制等核心模块代码经实测可稳定运行适合作为毕设选题或企业级Web开发实践参考。压缩包共179个文件含50个Java业务逻辑类、26个JSP页面、19个XML配置文件、21个JS前端脚本及配套CSS、图片、SQL建表脚本与项目文档整体容量117.58MB结构清晰、模块解耦度高。已有552人学习下载配套提供2个MP4辅导视频、2个PPT设计说明及完整部署文档涵盖环境配置、数据库初始化、关键Action与Service层调用链分析便于快速理解MVC流转与事务管理机制。1. 百货中心供应链的业务边界与模块拆解1.1 供应链管理系统到底解决什么问题百货中心的运营链条说起来并不复杂但真正落地就有很多细节让人头疼。供应商把货送到总仓仓库按楼层和柜台分拨各柜台的销售数据回来之后又需要反哺采购决策——这个流程里最怕的就是信息断档。采购员不知道哪些商品滞销仓库不知道哪些货快到保质期财务对账靠手工Excel都是实打实的效率黑洞。这个基于JavaEESSHMySQL的百货中心供应链管理系统本质上是把采购—入库—库存—销售—结算这条完整链条数字化。它不是一个简单的进销存软件而是带有明确角色分工和审批流设计的业务系统。系统里最常见的角色有系统管理员、采购员、仓管员、销售导购和门店经理不同角色看到的页面能操作的功能不一样柜台销售员能做的只是开销售单和查库存而采购单的审核、供应商信息的维护这些关键动作必须由相应权限的管理人员来完成。模块划分上我按业务域拆成了四块。第一块是基础资料管理包括商品档案、供应商档案、楼层柜台档案这是整个系统的数据地基第二块是采购管理覆盖采购订单的创建、审核、到货确认第三块是库存管理包括入库、出库、盘点、库存预警第四块是销售管理包含销售单录入、销售退货、日结汇总。最后加上系统管理模块去管用户、角色和菜单权限。这套系统适合谁如果你是计算机相关专业的学生正在选毕业设计题目或者刚工作不久想找一个完整项目来练手梳理JavaWeb分层开发思路这个项目的颗粒度非常合适。它不像电商系统那样有无穷多的业务分支但已经把供应链里最核心的闭环做完整了你既能看懂每一行代码又能向别人讲清楚每一个功能背后的业务逻辑。1.2 核心业务流程与数据流向要理解这套系统先抓住一条主线就好采购入库销售出库。业务从采购计划开始采购员选定供应商和商品填写数量与单价生成采购单。采购单经过审核人确认后形成有效的待入库单据仓管员在到货时按单收货系统自动增加对应商品的可用库存同时生成一条入库流水。销售端的流程是反向的。导购员开销售单系统先校验库存是否充足确认后扣减库存并生成销售流水。当天营业结束门店经理可以做日结操作汇总当日各柜台的销售额和利润这些数据最终会反馈给采购和财务做参考。数据流向方面前端JSP页面发起请求后请求先到达Struts2的过滤器链由ActionMapping找到对应的Action类Action调用Spring容器管理的Service层接口Service层内部通过Hibernate封装的DAO完成对MySQL的读写。这条链路从浏览器到数据库非常清晰也是理解SSH框架组合最好的切入点。我在设计的时候特别做了一个取舍库存流水表不允许轻易修改或删除所有库存变动必须有对应的业务单据ID关联。后来很多同类项目出问题就是砍掉了流水这个环节库存数字对不上时完全没有追溯线索。宁可多写一点代码也要保留这个审计链路。2. 技术选型为什么是SSHMySQL一套老牌组合的价值与局限2.1 Struts2、Spring、Hibernate各自承担什么角色很多人一看到SSH就以为是很遥远的技术其实这套组合里每一个框架解决的都是很具体的问题。Struts2负责Web层也就是接收HTTP请求、调用业务逻辑、控制页面跳转Spring负责对象管理和事务Service层实现类被Spring容器统一管理依赖注入之后Action不需要自己new对象Hibernate负责数据库访问把数据表和Java对象做映射开发者用面向对象的方式操作数据库不用写大量重复的JDBC代码。用一个餐饮的类比来解释Struts2是餐厅门口的服务员客人来了先接待问清楚要点什么菜然后通知后厨Spring是餐厅的店长管理着后厨每个人的岗位职责谁负责切菜谁负责炒菜还盯着每张单子的流程不能乱Hibernate是仓库管理员服务员和厨师都不需要自己去仓库翻货只要说我要土豆仓库就自动按登记的货架位置拿给他。Hibernate的ORM机制是这个项目的亮点。比如你有一个Supplier实体类对应数据库里的supplier表配置好映射关系后session.save(supplier)就能完成一条INSERTsession.get(Supplier.class, id)就能按主键查询。对基础CRUD来说代码量比原生JDBC少一半以上。不过这也意味着一旦遇到复杂查询HQL或SQL的书写就需要更多考量这一点后面讲实现细节时会展开说。2.2 分层架构与请求流转路径这个项目采用的是经典的三层架构外加一个Web表现层所以更准确地说应该是四层表现层、业务层、持久层和数据库层。表现层就是JSP和Struts2的Action业务层是Service接口及其实现类持久层是DAO接口和Hibernate的HibernateTemplate或者SessionFactory直接操作最底下是MySQL数据库。一个完整请求的流转路径大概是这样的浏览器发起请求比如访问/purchaseOrder_save.action。Tomcat收到请求后Struts2的StrutsPrepareAndExecuteFilter接管。过滤器根据Struts配置文件找到对应的Action类和execute方法。Struts2通过反射创建Action实例同时Spring容器把Service对象注入进来。Action里收集页面提交的参数封装成POJO对象调用Service的方法。Service层开启事务调用DAO完成数据库操作。返回结果后Struts2根据配置的result决定跳转到哪个JSP页面或返回JSON。这个分层的好处是职责单一每一层只做自己的事情。Action里不会出现SQL语句Service层不会出现HTTP参数解析DAO层也不会写页面的跳转逻辑。如果未来要把Struts2更换成Spring MVCAction层的代码需要改但Service层和DAO层的代码几乎可以原封不动地复用这就是分层设计带来的维护价值。2.3 为什么现在仍然值得做SSH项目你可能要问现在新项目都用Spring Boot MyBatis为什么还碰SSH我的观点是以学习和理解JavaWeb核心理念为目标SSH反而是一个很好的慢速解剖工具。Spring Boot把太多东西自动装配好了初学者反而不容易搞明白事务被谁控制、拦截器在哪里注册、Bean的生命周期是怎么回事。而SSH框架中每一个配置都是显式的你会在applicationContext.xml里亲手写下每一个bean和事务定义这个过程对底层原理的理解非常有帮助。另外一个现实原因是很多高校的课程设计和毕业设计题目仍然沿用SSH框架互联网上这个方向的历史教程和参考资料也极其丰富。你遇到任何一个报错几乎都能找到前人踩坑的记录。作为一个项目练手SSH能让你深刻理解MVC、IoC、AOP、ORM这些贯穿JavaWeb的核心概念以后再转Spring Boot或者Spring Cloud你会发现只是工具变了思想是通的。选MySQL也很好理解它轻量、免费、生态成熟对中小型系统完全够用。百货中心的业务量不算大单表几万条数据对MySQL来说毫无压力配合Navicat或者MySQL Workbench做数据管理也很方便。3. 数据库设计从实体关系到建表细节3.1 核心实体梳理与ER关系数据库设计是这类管理系统最重要的环节。表结构如果设计得混乱后面写代码会到处别扭。我梳理出以下核心实体用户表sys_user存登录账号、密码、姓名、所属楼层柜台。角色表sys_role存角色名称和描述比如管理员、采购员、仓管员、导购员。用户角色关联表sys_user_role用户和角色是多对多关系。菜单表sys_menu存系统菜单项和URL地址。角色菜单关联表sys_role_menu角色和菜单多对多关系。供应商表supplier存供应商名称、联系人、电话、地址。商品分类表category存分类名称和上级分类。商品表product存商品名称、条码、规格、单位、分类ID、进价、售价、预警库存值。柜台表counter存楼层、区域、负责人。采购单表purchase_order存采购单号、供应商ID、采购员ID、总金额、状态、审核人、审核时间。采购单明细表purchase_order_item存采购单主表ID、商品ID、数量、进价、小计。库存表stock存商品ID、柜台ID、当前库存、锁定库存、预警值。库存流水表stock_flow存商品ID、柜台ID、变动类型、数量、关联业务单号、操作时间。销售单表sale_order存销售单号、柜台ID、导购员ID、总金额、状态。销售单明细表sale_order_item存销售单主表ID、商品ID、数量、售价、小计。这些实体之间的核心关系是商品属于某个分类采购单关联供应商采购单明细关联商品库存关联商品和柜台销售单明细关联商品库存在每次采购和销售后联动产生流水。整体关系不算特别复杂但是主外键关联必须清晰否则后面写关联查询的时候会很吃力。3.2 重点表结构与字段设计说明我把最关键的商品表、采购单主表、库存表和库存流水表的结构拿出来看一下字段设计上是经过取舍的。商品表product字段名类型说明idint主键自增product_codevarchar(50)商品编码唯一索引product_namevarchar(100)商品名称barcodevarchar(50)条码category_idint分类ID外键关联category表specvarchar(100)规格型号unitvarchar(20)计量单位purchase_pricedecimal(10,2)进价sale_pricedecimal(10,2)售价warn_stockint预警库存量statustinyint状态1上架 0下架采购单主表purchase_order字段名类型说明idint主键自增order_novarchar(50)采购单号形如PO20240520001supplier_idint供应商IDcreate_user_idint制单员IDtotal_amountdecimal(12,2)总金额statustinyint0草稿 1待审核 2已审核 3已入库 4已作废audit_user_idint审核人IDaudit_timedatetime审核时间create_timedatetime创建时间库存表stock的独特之处在于它是按商品柜台维度存储的也就是说同一个商品在不同楼层柜台的库存是独立记录的。查询总库存时按商品ID做SUM聚合即可。这个设计更贴合百货中心实际场景因为商品确实会分布在不同的柜台销售。库存流水表stock_flow的变动类型我用了一个字典字段1代表采购入库2代表销售出库3代表盘点调整4代表退货入库5代表报损出库。通过关联业务单号字段可以追溯到每一条流水对应的是哪张采购单或销售单这对日后的排查和审计至关重要。3.3 建表时的索引与约束细节数据库设计不能只画ER图具体到建表SQL有几个细节值得注意。第一所有外键字段建议加上索引但不一定都建立物理外键约束。物理外键在某些批量操作场景下会影响性能项目里我更倾向于在应用层维护完整性只保留逻辑外键配合必要的索引。比如product表的category_id、purchase_order表的supplier_id、stock表的product_id都建议加上普通索引。第二唯一性约束很重要。商品编码必须唯一采购单号必须唯一用户登录账号必须唯一。唯一索引能防止并发情况下的重复数据比在代码里先查询再判断要可靠得多。第三金额字段一律使用decimal而不是float或double。这个已经是常识了但还是有人会踩坑浮点数在金额运算中可能产生精度误差账目对不上就很麻烦。第四所有的业务表都建议加上create_time和update_time两个时间字段。做数据分析和排查问题时时间字段能帮你快速定位问题发生的时间点。状态字段用一个tinyint存数字字典即可比字符串更省空间配合代码里的常量定义可读性也完全够。针对百货中心这种业务规模不考虑分库分表单库单实例就完全够用。如果你有一天希望扩展成多门店的版本最需要改的是从stock表拆分出门店维度字段目前在柜台维度上做预留也有利于后续的横向演进。4. 核心功能实现链路一个采购入库单如何走完全程4.1 表现层Struts2 Action接收请求与参数封装我选一个最典型的业务流程来拆解代码实现采购入库。所谓采购入库本质上是采购单从审核状态变成已入库状态库存增加流水落库这三个动作的原子性完成。先从表现层开始。新建采购单的页面是一张主表加一个明细列表JSP页面使用s:form标签和s:textfield标签绑定表单字段。提交请求时Struts2会把表单参数自动封装到Action中的PurchaseOrder对象里。public class PurchaseOrderAction extends ActionSupport { private PurchaseOrder purchaseOrder; private ListPurchaseOrderItem items; private PurchaseOrderService purchaseOrderService; // 省略getter/setter public String save() { try { purchaseOrderService.savePurchaseOrder(purchaseOrder, items); addActionMessage(保存成功); } catch (Exception e) { addActionError(保存失败 e.getMessage()); } return SUCCESS; } public String audit() { purchaseOrderService.auditPurchaseOrder(purchaseOrder.getId(), currentUser.getId()); return SUCCESS; } }Action里不会直接出现任何业务判断它只做两件事接收页面参数调用Service层方法根据结果决定返回哪种视图。这里有一个Struts2的要点如果页面传来的是List对象name属性要写成items[0].productId、items[1].quantity这种形式Struts2的OGNL表达式才能正确完成嵌套对象的批量封装。4.2 业务层事务控制与库存联动Service层是整个流程的重心。我把savePurchaseOrder和auditPurchaseOrder分开所有写操作都配置了Spring声明式事务。在Spring配置文件里定义事务管理器并把事务通知织入到Service类的相应方法上。保存采购单的逻辑相对简单就是先保存主表获取自增ID然后遍历明细表给每一条明细补上主表ID再保存。这里需要判断明细不能为空商品不能重复数量必须大于0。审核采购单是这个项目里最核心的业务逻辑。审核通过后系统需要做三件事更新采购单状态为已审核遍历采购单明细给对应商品增加库存为每条明细生成一条入库类型的库存流水。Transactional(rollbackFor Exception.class) public void auditPurchaseOrder(Integer orderId, Integer auditorId) { PurchaseOrder order purchaseOrderDao.get(orderId); if (order null || order.getStatus() ! 1) { throw new BusinessException(采购单不存在或不是待审核状态); } order.setStatus(2); order.setAuditUserId(auditorId); order.setAuditTime(new Date()); purchaseOrderDao.update(order); ListPurchaseOrderItem items purchaseOrderItemDao.findByOrderId(orderId); for (PurchaseOrderItem item : items) { Stock stock stockDao.findByProductAndCounter(item.getProductId(), order.getCounterId()); if (stock null) { stock new Stock(); stock.setProductId(item.getProductId()); stock.setCounterId(order.getCounterId()); stock.setQuantity(item.getQuantity()); stockDao.save(stock); } else { stock.setQuantity(stock.getQuantity() item.getQuantity()); stockDao.update(stock); } StockFlow flow new StockFlow(); flow.setProductId(item.getProductId()); flow.setCounterId(order.getCounterId()); flow.setChangeType(1); flow.setChangeQuantity(item.getQuantity()); flow.setBizOrderNo(order.getOrderNo()); flow.setCreateTime(new Date()); stockFlowDao.save(flow); } }注意Transactional注解回滚条件是任何异常都会触发。这样设计的目的很明确如果库存已经更新但流水保存失败整个操作就要全部回滚不能出现库存多了但没记录这种脏数据情况。这个保证机制在财务对账时非常重要。4.3 持久层Hibernate映射与DAO封装持久层我用Hibernate的SessionFactory实现通用DAO。每个实体类对应一个.hbm.xml映射文件比如PurchaseOrder.hbm.xml里定义主键生成策略为native属性列映射通过property标签完成。Repository public class StockDaoImpl implements StockDao { Resource private SessionFactory sessionFactory; Override public Stock findByProductAndCounter(Integer productId, Integer counterId) { String hql from Stock where productId :productId and counterId :counterId; Query query sessionFactory.getCurrentSession().createQuery(hql); query.setParameter(productId, productId); query.setParameter(counterId, counterId); return (Stock) query.uniqueResult(); } }在Hibernate查询里字段名是Java实体的属性名不是数据库列名这一点要特别注意。如果实体属性是驼峰命名productId数据库列名可能是product_id映射关系由hbm文件维护但HQL里一定要写属性名。对库存扣减这种对数据一致性要求高的操作我建议使用悲观锁。在DAO查询时使用session.get(Stock.class, id, LockMode.PESSIMISTIC_WRITE)或者写HQL时加for update让数据库锁定这一行防止并发销售导致超卖。这个项目里虽然并发量不大但作为完整方案锁的使用是必须考虑的。4.4 销售出库与库存扣减的反向流程销售出库是采购入库的镜像流程。导购员在前端选择商品、填写数量系统先做库存校验如果当前柜台的库存数量小于销售数量直接提示库存不足不允许提交。校验通过后生成销售单扣减库存生成销售流水。这个过程中有一个细节是扣减库存时要同时考虑锁定库存。简单系统的做法是只用一个quantity字段但更严谨的设计会区分可用库存和锁定库存。比如一份采购单审核后货品还在入库验收环节锁定库存增加验收完成再转成可用库存。这个项目做了简化只保留可用库存但我在文档中写明了扩展方向需要的人可以自行添加字段。一个比较容易忽略的问题是退货流程。如果销售退货发生库存要回补同时销售单要记录退货状态否则销售汇总数据会出错。我把退货设计成直接对原销售单做红冲处理也就是新增一条销售数量为负的明细记录这样报表统计自然抵消不需要额外维护复杂的冲正逻辑。5. 系统部署、配置与开发中踩过的坑5.1 开发环境搭建与版本匹配环境搭建是每个做SSH项目的同学都会经历的一道坎。我的建议是直接使用如下组合JDK 1.8Tomcat 8.5Struts2 2.5.xSpring 4.3.xHibernate 4.3.xMySQL 5.7。这套组合经过了大量项目验证兼容性最稳。如果你用的是MySQL 8.x驱动类名需要从com.mysql.jdbc.Driver改为com.mysql.cj.jdbc.Driver同时在JDBC连接串里加上serverTimezoneAsia/Shanghai和useSSLfalse否则启动时大概率会报时区错误或者SSL连接告警。在IDE的选择上我用的是Eclipse for JavaEE版本直接自带Tomcat插件对老项目的支持比较友好。如果你习惯IDEA也可以但要注意IDEA对Tomcat热部署的支持在部分情况下会让静态资源的更新不及时调试时多按一次CtrlF10就好了。5.2 配置文件最容易出错的地方SSH项目的配置是重灾区我几乎可以断定每个人至少会在这个环节卡一次。最容易出错的几个点如下Spring配置文件的引入顺序。applicationContext.xml里如果采用import resourceclasspath:applicationContext-dao.xml/这种方式引入多个子配置文件子文件中bean的依赖关系必须能被Spring容器扫到否则启动时会报NoSuchBeanDefinitionException。建议将数据源、SessionFactory、事务管理器放在核心配置文件中DAO、Service、Action分别用context:component-scan扫描。Struts2和Spring整合时Action实例的创建问题。如果Struts2配置里Action的class属性直接写类的全限定名那么每次请求都会创建一个全新的Action实例。如果想使用Spring容器中单例的Action实例需要配置Struts2的Spring插件并确保在struts.xml里constant namestruts.objectFactory valuespring /。不配置这个注入到Action里的Service就可能是null。Hibernate的Session和事务绑定。Hibernate的getCurrentSession()必须在有事务的环境下使用否则会报Could not obtain transaction-synchronized Session for current thread。解决办法是在Spring配置里把hibernate.current_session_context_class设置为org.springframework.orm.hibernate4.SpringSessionContext同时让事务管理器接管Session的生命周期。懒加载异常。默认情况下Hibernate使用懒加载当实体关联的其他实体在Session关闭后才被访问时会抛出LazyInitializationException。最简单的解决办法是在web.xml里配置OpenSessionInViewFilter让Session的生命周期延长到整个请求结束。不过这只是权宜之计更大的数据量项目还是要用JOIN FETCH或批量抓取策略来优化。5.3 常见运行期异常与解决方案我把自己在这类项目开发过程中真正遇到过的问题整理成了一张速查表希望对你有直接的帮助。异常现象根本原因解决办法中文乱码JSP页面编码和数据库编码不一致统一UTF-8页面pageEncodingUTF-8连接串加characterEncodingutf8数据库表字符集设置为utf8mb4同时配置Spring的CharacterEncodingFilterHTTP 500: No result defined for action and result inputStruts2的Action方法返回字符串没有在struts.xml中配置对应的result检查所有可能的返回值success、error、input等都要有对应的result定义ClassNotFoundException: com.mysql.jdbc.Driver缺少MySQL驱动jar包或者MySQL版本和驱动版本不匹配在Tomcat的lib目录或项目的WEB-INF/lib下放置mysql-connector-java对应版本的jar包BeanCreationException: Dependency injection failedSpring容器中依赖的Service或DAO没有被扫描到检查context:component-scan的base-package是否覆盖了所有需要扫描的包数据查询出来是nullHibernate实体映射字段名与数据库列名不一致检查.hbm.xml中property的name和column属性是否对应正确还有一个关于Tomcat部署的提醒如果修改了struts.xml或applicationContext.xml但没有重启Tomcat有时候新配置不生效这是因为Tomcat对配置文件的热加载并不总是可靠的。遇到这种情况不要怀疑代码直接Clean项目、重启Tomcat问题八成能解决。5.4 从项目角度谈源码注释与文档的重要性这个项目标题里写了源码文档我在交付的时候特别在意代码的可信性和可维护性。写代码时每层接口都加了Javadoc注释说明这个方法的入参、出参和业务逻辑核心方法比如采购单审核、销售退货我还在注释里画了简单的步骤说明。因为SSH项目不像Spring Boot那样有众多自动配置代码里到处都是配置细节如果没有注释一个新人接手这个项目至少需要一整天才能理清各层之间的关系。配套的文档部分我写了三类。第一类是需求分析文档把每个功能模块的输入、输出、处理流程描述清楚第二类是数据库设计说明书包括ER图、表结构说明、字段字典第三类是部署手册从JDK安装到Tomcat发布一步步讲。我强烈建议每一个做类似项目的同学即使不要求交文档也要把设计和实现思路记录下来。这会倒逼你把业务逻辑想清楚而不是边写边改。项目里我专门用了一个工具类OrderNoGenerator来生成订单号规则是前缀加日期再加当天序号比如PO20240520001。这个类有一点要注意如果用SimpleDateFormat加System.currentTimeMillis()来拼单号在高并发场景下可能会出现重复所以在生成代码里加了synchronized保证线程安全。虽然是课程设计级别的项目但这种细节体现的是工程素养。6. 后续演进与个人实操心得把SSH版本跑通之后如果你还有精力我建议往两个方向做演进。第一个方向是前后端分离改造保留Service层和DAO层不动把表现层的JSPStruts2替换成RESTful接口加Vue或React页面这样整个项目就变成了现代化的前后端分离架构。第二个方向是引入Maven和持续集成把手动拷jar包的方式改成pom.xml依赖管理再配合Git做版本控制项目工程化程度会高一个档次。另外我想特别提一下单元测试的价值。SSH项目的事务配置和Hibernate映射如果出了问题单靠启动Tomcat做黑盒测试定位问题很慢。我给Service层写了几个核心测试用例用SpringTest配合H2内存库跑采购单审核通过后库存增加的数量和流水记录都能在几秒内验证完毕。首次配置H2和MySQL的方言切换需要一点时间但一旦跑通后面改代码的底气就足很多。关于这个项目我还想说一点个人体会不要轻视那些看起来老的技术。我在做这个项目的过程中对Spring的IoC和AOP理解比之前用Spring Boot时深入了很多因为一切配置都是显式的你被迫搞明白每一个Bean是怎么来的。Hibernate的Session缓存机制、懒加载策略、事务边界这些概念都是在SSH这种没那么智能的框架里逐步弄清楚的。现在回到Spring Boot,遇到事务失效或者懒加载报错这类问题我就知道它底层是什么原因排查起来心里有数。这个百货中心供应链管理系统完整覆盖了JavaWeb开发的核心技术栈也覆盖了供应链业务里面最关键的采购、库存、销售闭环。如果你今年需要做类似的课程设计或毕业设计建议在跑通这个项目的基础上增加一个你自己感兴趣的功能点比如采购数据可视化分析、供应商评价或者销售预测这会成为答辩时最亮眼的加分项。本文还有配套的精品资源点击获取 基于SSH的百货中心供应链管理系统设计与实现
简介本资源是一套面向高校计算机专业本科生毕业设计与课程实训的完整供应链管理系统实现方案基于JavaEE平台采用SSHStruts2SpringHibernate经典三层架构结合MySQL数据库构建百货中心级业务场景。系统覆盖采购管理、销售管理、库存监控、供应商协作及用户权限控制等核心模块代码经实测可稳定运行适合作为毕设选题或企业级Web开发实践参考。压缩包共179个文件含50个Java业务逻辑类、26个JSP页面、19个XML配置文件、21个JS前端脚本及配套CSS、图片、SQL建表脚本与项目文档整体容量117.58MB结构清晰、模块解耦度高。已有552人学习下载配套提供2个MP4辅导视频、2个PPT设计说明及完整部署文档涵盖环境配置、数据库初始化、关键Action与Service层调用链分析便于快速理解MVC流转与事务管理机制。1. 百货中心供应链的业务边界与模块拆解1.1 供应链管理系统到底解决什么问题百货中心的运营链条说起来并不复杂但真正落地就有很多细节让人头疼。供应商把货送到总仓仓库按楼层和柜台分拨各柜台的销售数据回来之后又需要反哺采购决策——这个流程里最怕的就是信息断档。采购员不知道哪些商品滞销仓库不知道哪些货快到保质期财务对账靠手工Excel都是实打实的效率黑洞。这个基于JavaEESSHMySQL的百货中心供应链管理系统本质上是把采购—入库—库存—销售—结算这条完整链条数字化。它不是一个简单的进销存软件而是带有明确角色分工和审批流设计的业务系统。系统里最常见的角色有系统管理员、采购员、仓管员、销售导购和门店经理不同角色看到的页面能操作的功能不一样柜台销售员能做的只是开销售单和查库存而采购单的审核、供应商信息的维护这些关键动作必须由相应权限的管理人员来完成。模块划分上我按业务域拆成了四块。第一块是基础资料管理包括商品档案、供应商档案、楼层柜台档案这是整个系统的数据地基第二块是采购管理覆盖采购订单的创建、审核、到货确认第三块是库存管理包括入库、出库、盘点、库存预警第四块是销售管理包含销售单录入、销售退货、日结汇总。最后加上系统管理模块去管用户、角色和菜单权限。这套系统适合谁如果你是计算机相关专业的学生正在选毕业设计题目或者刚工作不久想找一个完整项目来练手梳理JavaWeb分层开发思路这个项目的颗粒度非常合适。它不像电商系统那样有无穷多的业务分支但已经把供应链里最核心的闭环做完整了你既能看懂每一行代码又能向别人讲清楚每一个功能背后的业务逻辑。1.2 核心业务流程与数据流向要理解这套系统先抓住一条主线就好采购入库销售出库。业务从采购计划开始采购员选定供应商和商品填写数量与单价生成采购单。采购单经过审核人确认后形成有效的待入库单据仓管员在到货时按单收货系统自动增加对应商品的可用库存同时生成一条入库流水。销售端的流程是反向的。导购员开销售单系统先校验库存是否充足确认后扣减库存并生成销售流水。当天营业结束门店经理可以做日结操作汇总当日各柜台的销售额和利润这些数据最终会反馈给采购和财务做参考。数据流向方面前端JSP页面发起请求后请求先到达Struts2的过滤器链由ActionMapping找到对应的Action类Action调用Spring容器管理的Service层接口Service层内部通过Hibernate封装的DAO完成对MySQL的读写。这条链路从浏览器到数据库非常清晰也是理解SSH框架组合最好的切入点。我在设计的时候特别做了一个取舍库存流水表不允许轻易修改或删除所有库存变动必须有对应的业务单据ID关联。后来很多同类项目出问题就是砍掉了流水这个环节库存数字对不上时完全没有追溯线索。宁可多写一点代码也要保留这个审计链路。2. 技术选型为什么是SSHMySQL一套老牌组合的价值与局限2.1 Struts2、Spring、Hibernate各自承担什么角色很多人一看到SSH就以为是很遥远的技术其实这套组合里每一个框架解决的都是很具体的问题。Struts2负责Web层也就是接收HTTP请求、调用业务逻辑、控制页面跳转Spring负责对象管理和事务Service层实现类被Spring容器统一管理依赖注入之后Action不需要自己new对象Hibernate负责数据库访问把数据表和Java对象做映射开发者用面向对象的方式操作数据库不用写大量重复的JDBC代码。用一个餐饮的类比来解释Struts2是餐厅门口的服务员客人来了先接待问清楚要点什么菜然后通知后厨Spring是餐厅的店长管理着后厨每个人的岗位职责谁负责切菜谁负责炒菜还盯着每张单子的流程不能乱Hibernate是仓库管理员服务员和厨师都不需要自己去仓库翻货只要说我要土豆仓库就自动按登记的货架位置拿给他。Hibernate的ORM机制是这个项目的亮点。比如你有一个Supplier实体类对应数据库里的supplier表配置好映射关系后session.save(supplier)就能完成一条INSERTsession.get(Supplier.class, id)就能按主键查询。对基础CRUD来说代码量比原生JDBC少一半以上。不过这也意味着一旦遇到复杂查询HQL或SQL的书写就需要更多考量这一点后面讲实现细节时会展开说。2.2 分层架构与请求流转路径这个项目采用的是经典的三层架构外加一个Web表现层所以更准确地说应该是四层表现层、业务层、持久层和数据库层。表现层就是JSP和Struts2的Action业务层是Service接口及其实现类持久层是DAO接口和Hibernate的HibernateTemplate或者SessionFactory直接操作最底下是MySQL数据库。一个完整请求的流转路径大概是这样的浏览器发起请求比如访问/purchaseOrder_save.action。Tomcat收到请求后Struts2的StrutsPrepareAndExecuteFilter接管。过滤器根据Struts配置文件找到对应的Action类和execute方法。Struts2通过反射创建Action实例同时Spring容器把Service对象注入进来。Action里收集页面提交的参数封装成POJO对象调用Service的方法。Service层开启事务调用DAO完成数据库操作。返回结果后Struts2根据配置的result决定跳转到哪个JSP页面或返回JSON。这个分层的好处是职责单一每一层只做自己的事情。Action里不会出现SQL语句Service层不会出现HTTP参数解析DAO层也不会写页面的跳转逻辑。如果未来要把Struts2更换成Spring MVCAction层的代码需要改但Service层和DAO层的代码几乎可以原封不动地复用这就是分层设计带来的维护价值。2.3 为什么现在仍然值得做SSH项目你可能要问现在新项目都用Spring Boot MyBatis为什么还碰SSH我的观点是以学习和理解JavaWeb核心理念为目标SSH反而是一个很好的慢速解剖工具。Spring Boot把太多东西自动装配好了初学者反而不容易搞明白事务被谁控制、拦截器在哪里注册、Bean的生命周期是怎么回事。而SSH框架中每一个配置都是显式的你会在applicationContext.xml里亲手写下每一个bean和事务定义这个过程对底层原理的理解非常有帮助。另外一个现实原因是很多高校的课程设计和毕业设计题目仍然沿用SSH框架互联网上这个方向的历史教程和参考资料也极其丰富。你遇到任何一个报错几乎都能找到前人踩坑的记录。作为一个项目练手SSH能让你深刻理解MVC、IoC、AOP、ORM这些贯穿JavaWeb的核心概念以后再转Spring Boot或者Spring Cloud你会发现只是工具变了思想是通的。选MySQL也很好理解它轻量、免费、生态成熟对中小型系统完全够用。百货中心的业务量不算大单表几万条数据对MySQL来说毫无压力配合Navicat或者MySQL Workbench做数据管理也很方便。3. 数据库设计从实体关系到建表细节3.1 核心实体梳理与ER关系数据库设计是这类管理系统最重要的环节。表结构如果设计得混乱后面写代码会到处别扭。我梳理出以下核心实体用户表sys_user存登录账号、密码、姓名、所属楼层柜台。角色表sys_role存角色名称和描述比如管理员、采购员、仓管员、导购员。用户角色关联表sys_user_role用户和角色是多对多关系。菜单表sys_menu存系统菜单项和URL地址。角色菜单关联表sys_role_menu角色和菜单多对多关系。供应商表supplier存供应商名称、联系人、电话、地址。商品分类表category存分类名称和上级分类。商品表product存商品名称、条码、规格、单位、分类ID、进价、售价、预警库存值。柜台表counter存楼层、区域、负责人。采购单表purchase_order存采购单号、供应商ID、采购员ID、总金额、状态、审核人、审核时间。采购单明细表purchase_order_item存采购单主表ID、商品ID、数量、进价、小计。库存表stock存商品ID、柜台ID、当前库存、锁定库存、预警值。库存流水表stock_flow存商品ID、柜台ID、变动类型、数量、关联业务单号、操作时间。销售单表sale_order存销售单号、柜台ID、导购员ID、总金额、状态。销售单明细表sale_order_item存销售单主表ID、商品ID、数量、售价、小计。这些实体之间的核心关系是商品属于某个分类采购单关联供应商采购单明细关联商品库存关联商品和柜台销售单明细关联商品库存在每次采购和销售后联动产生流水。整体关系不算特别复杂但是主外键关联必须清晰否则后面写关联查询的时候会很吃力。3.2 重点表结构与字段设计说明我把最关键的商品表、采购单主表、库存表和库存流水表的结构拿出来看一下字段设计上是经过取舍的。商品表product字段名类型说明idint主键自增product_codevarchar(50)商品编码唯一索引product_namevarchar(100)商品名称barcodevarchar(50)条码category_idint分类ID外键关联category表specvarchar(100)规格型号unitvarchar(20)计量单位purchase_pricedecimal(10,2)进价sale_pricedecimal(10,2)售价warn_stockint预警库存量statustinyint状态1上架 0下架采购单主表purchase_order字段名类型说明idint主键自增order_novarchar(50)采购单号形如PO20240520001supplier_idint供应商IDcreate_user_idint制单员IDtotal_amountdecimal(12,2)总金额statustinyint0草稿 1待审核 2已审核 3已入库 4已作废audit_user_idint审核人IDaudit_timedatetime审核时间create_timedatetime创建时间库存表stock的独特之处在于它是按商品柜台维度存储的也就是说同一个商品在不同楼层柜台的库存是独立记录的。查询总库存时按商品ID做SUM聚合即可。这个设计更贴合百货中心实际场景因为商品确实会分布在不同的柜台销售。库存流水表stock_flow的变动类型我用了一个字典字段1代表采购入库2代表销售出库3代表盘点调整4代表退货入库5代表报损出库。通过关联业务单号字段可以追溯到每一条流水对应的是哪张采购单或销售单这对日后的排查和审计至关重要。3.3 建表时的索引与约束细节数据库设计不能只画ER图具体到建表SQL有几个细节值得注意。第一所有外键字段建议加上索引但不一定都建立物理外键约束。物理外键在某些批量操作场景下会影响性能项目里我更倾向于在应用层维护完整性只保留逻辑外键配合必要的索引。比如product表的category_id、purchase_order表的supplier_id、stock表的product_id都建议加上普通索引。第二唯一性约束很重要。商品编码必须唯一采购单号必须唯一用户登录账号必须唯一。唯一索引能防止并发情况下的重复数据比在代码里先查询再判断要可靠得多。第三金额字段一律使用decimal而不是float或double。这个已经是常识了但还是有人会踩坑浮点数在金额运算中可能产生精度误差账目对不上就很麻烦。第四所有的业务表都建议加上create_time和update_time两个时间字段。做数据分析和排查问题时时间字段能帮你快速定位问题发生的时间点。状态字段用一个tinyint存数字字典即可比字符串更省空间配合代码里的常量定义可读性也完全够。针对百货中心这种业务规模不考虑分库分表单库单实例就完全够用。如果你有一天希望扩展成多门店的版本最需要改的是从stock表拆分出门店维度字段目前在柜台维度上做预留也有利于后续的横向演进。4. 核心功能实现链路一个采购入库单如何走完全程4.1 表现层Struts2 Action接收请求与参数封装我选一个最典型的业务流程来拆解代码实现采购入库。所谓采购入库本质上是采购单从审核状态变成已入库状态库存增加流水落库这三个动作的原子性完成。先从表现层开始。新建采购单的页面是一张主表加一个明细列表JSP页面使用s:form标签和s:textfield标签绑定表单字段。提交请求时Struts2会把表单参数自动封装到Action中的PurchaseOrder对象里。public class PurchaseOrderAction extends ActionSupport { private PurchaseOrder purchaseOrder; private ListPurchaseOrderItem items; private PurchaseOrderService purchaseOrderService; // 省略getter/setter public String save() { try { purchaseOrderService.savePurchaseOrder(purchaseOrder, items); addActionMessage(保存成功); } catch (Exception e) { addActionError(保存失败 e.getMessage()); } return SUCCESS; } public String audit() { purchaseOrderService.auditPurchaseOrder(purchaseOrder.getId(), currentUser.getId()); return SUCCESS; } }Action里不会直接出现任何业务判断它只做两件事接收页面参数调用Service层方法根据结果决定返回哪种视图。这里有一个Struts2的要点如果页面传来的是List对象name属性要写成items[0].productId、items[1].quantity这种形式Struts2的OGNL表达式才能正确完成嵌套对象的批量封装。4.2 业务层事务控制与库存联动Service层是整个流程的重心。我把savePurchaseOrder和auditPurchaseOrder分开所有写操作都配置了Spring声明式事务。在Spring配置文件里定义事务管理器并把事务通知织入到Service类的相应方法上。保存采购单的逻辑相对简单就是先保存主表获取自增ID然后遍历明细表给每一条明细补上主表ID再保存。这里需要判断明细不能为空商品不能重复数量必须大于0。审核采购单是这个项目里最核心的业务逻辑。审核通过后系统需要做三件事更新采购单状态为已审核遍历采购单明细给对应商品增加库存为每条明细生成一条入库类型的库存流水。Transactional(rollbackFor Exception.class) public void auditPurchaseOrder(Integer orderId, Integer auditorId) { PurchaseOrder order purchaseOrderDao.get(orderId); if (order null || order.getStatus() ! 1) { throw new BusinessException(采购单不存在或不是待审核状态); } order.setStatus(2); order.setAuditUserId(auditorId); order.setAuditTime(new Date()); purchaseOrderDao.update(order); ListPurchaseOrderItem items purchaseOrderItemDao.findByOrderId(orderId); for (PurchaseOrderItem item : items) { Stock stock stockDao.findByProductAndCounter(item.getProductId(), order.getCounterId()); if (stock null) { stock new Stock(); stock.setProductId(item.getProductId()); stock.setCounterId(order.getCounterId()); stock.setQuantity(item.getQuantity()); stockDao.save(stock); } else { stock.setQuantity(stock.getQuantity() item.getQuantity()); stockDao.update(stock); } StockFlow flow new StockFlow(); flow.setProductId(item.getProductId()); flow.setCounterId(order.getCounterId()); flow.setChangeType(1); flow.setChangeQuantity(item.getQuantity()); flow.setBizOrderNo(order.getOrderNo()); flow.setCreateTime(new Date()); stockFlowDao.save(flow); } }注意Transactional注解回滚条件是任何异常都会触发。这样设计的目的很明确如果库存已经更新但流水保存失败整个操作就要全部回滚不能出现库存多了但没记录这种脏数据情况。这个保证机制在财务对账时非常重要。4.3 持久层Hibernate映射与DAO封装持久层我用Hibernate的SessionFactory实现通用DAO。每个实体类对应一个.hbm.xml映射文件比如PurchaseOrder.hbm.xml里定义主键生成策略为native属性列映射通过property标签完成。Repository public class StockDaoImpl implements StockDao { Resource private SessionFactory sessionFactory; Override public Stock findByProductAndCounter(Integer productId, Integer counterId) { String hql from Stock where productId :productId and counterId :counterId; Query query sessionFactory.getCurrentSession().createQuery(hql); query.setParameter(productId, productId); query.setParameter(counterId, counterId); return (Stock) query.uniqueResult(); } }在Hibernate查询里字段名是Java实体的属性名不是数据库列名这一点要特别注意。如果实体属性是驼峰命名productId数据库列名可能是product_id映射关系由hbm文件维护但HQL里一定要写属性名。对库存扣减这种对数据一致性要求高的操作我建议使用悲观锁。在DAO查询时使用session.get(Stock.class, id, LockMode.PESSIMISTIC_WRITE)或者写HQL时加for update让数据库锁定这一行防止并发销售导致超卖。这个项目里虽然并发量不大但作为完整方案锁的使用是必须考虑的。4.4 销售出库与库存扣减的反向流程销售出库是采购入库的镜像流程。导购员在前端选择商品、填写数量系统先做库存校验如果当前柜台的库存数量小于销售数量直接提示库存不足不允许提交。校验通过后生成销售单扣减库存生成销售流水。这个过程中有一个细节是扣减库存时要同时考虑锁定库存。简单系统的做法是只用一个quantity字段但更严谨的设计会区分可用库存和锁定库存。比如一份采购单审核后货品还在入库验收环节锁定库存增加验收完成再转成可用库存。这个项目做了简化只保留可用库存但我在文档中写明了扩展方向需要的人可以自行添加字段。一个比较容易忽略的问题是退货流程。如果销售退货发生库存要回补同时销售单要记录退货状态否则销售汇总数据会出错。我把退货设计成直接对原销售单做红冲处理也就是新增一条销售数量为负的明细记录这样报表统计自然抵消不需要额外维护复杂的冲正逻辑。5. 系统部署、配置与开发中踩过的坑5.1 开发环境搭建与版本匹配环境搭建是每个做SSH项目的同学都会经历的一道坎。我的建议是直接使用如下组合JDK 1.8Tomcat 8.5Struts2 2.5.xSpring 4.3.xHibernate 4.3.xMySQL 5.7。这套组合经过了大量项目验证兼容性最稳。如果你用的是MySQL 8.x驱动类名需要从com.mysql.jdbc.Driver改为com.mysql.cj.jdbc.Driver同时在JDBC连接串里加上serverTimezoneAsia/Shanghai和useSSLfalse否则启动时大概率会报时区错误或者SSL连接告警。在IDE的选择上我用的是Eclipse for JavaEE版本直接自带Tomcat插件对老项目的支持比较友好。如果你习惯IDEA也可以但要注意IDEA对Tomcat热部署的支持在部分情况下会让静态资源的更新不及时调试时多按一次CtrlF10就好了。5.2 配置文件最容易出错的地方SSH项目的配置是重灾区我几乎可以断定每个人至少会在这个环节卡一次。最容易出错的几个点如下Spring配置文件的引入顺序。applicationContext.xml里如果采用import resourceclasspath:applicationContext-dao.xml/这种方式引入多个子配置文件子文件中bean的依赖关系必须能被Spring容器扫到否则启动时会报NoSuchBeanDefinitionException。建议将数据源、SessionFactory、事务管理器放在核心配置文件中DAO、Service、Action分别用context:component-scan扫描。Struts2和Spring整合时Action实例的创建问题。如果Struts2配置里Action的class属性直接写类的全限定名那么每次请求都会创建一个全新的Action实例。如果想使用Spring容器中单例的Action实例需要配置Struts2的Spring插件并确保在struts.xml里constant namestruts.objectFactory valuespring /。不配置这个注入到Action里的Service就可能是null。Hibernate的Session和事务绑定。Hibernate的getCurrentSession()必须在有事务的环境下使用否则会报Could not obtain transaction-synchronized Session for current thread。解决办法是在Spring配置里把hibernate.current_session_context_class设置为org.springframework.orm.hibernate4.SpringSessionContext同时让事务管理器接管Session的生命周期。懒加载异常。默认情况下Hibernate使用懒加载当实体关联的其他实体在Session关闭后才被访问时会抛出LazyInitializationException。最简单的解决办法是在web.xml里配置OpenSessionInViewFilter让Session的生命周期延长到整个请求结束。不过这只是权宜之计更大的数据量项目还是要用JOIN FETCH或批量抓取策略来优化。5.3 常见运行期异常与解决方案我把自己在这类项目开发过程中真正遇到过的问题整理成了一张速查表希望对你有直接的帮助。异常现象根本原因解决办法中文乱码JSP页面编码和数据库编码不一致统一UTF-8页面pageEncodingUTF-8连接串加characterEncodingutf8数据库表字符集设置为utf8mb4同时配置Spring的CharacterEncodingFilterHTTP 500: No result defined for action and result inputStruts2的Action方法返回字符串没有在struts.xml中配置对应的result检查所有可能的返回值success、error、input等都要有对应的result定义ClassNotFoundException: com.mysql.jdbc.Driver缺少MySQL驱动jar包或者MySQL版本和驱动版本不匹配在Tomcat的lib目录或项目的WEB-INF/lib下放置mysql-connector-java对应版本的jar包BeanCreationException: Dependency injection failedSpring容器中依赖的Service或DAO没有被扫描到检查context:component-scan的base-package是否覆盖了所有需要扫描的包数据查询出来是nullHibernate实体映射字段名与数据库列名不一致检查.hbm.xml中property的name和column属性是否对应正确还有一个关于Tomcat部署的提醒如果修改了struts.xml或applicationContext.xml但没有重启Tomcat有时候新配置不生效这是因为Tomcat对配置文件的热加载并不总是可靠的。遇到这种情况不要怀疑代码直接Clean项目、重启Tomcat问题八成能解决。5.4 从项目角度谈源码注释与文档的重要性这个项目标题里写了源码文档我在交付的时候特别在意代码的可信性和可维护性。写代码时每层接口都加了Javadoc注释说明这个方法的入参、出参和业务逻辑核心方法比如采购单审核、销售退货我还在注释里画了简单的步骤说明。因为SSH项目不像Spring Boot那样有众多自动配置代码里到处都是配置细节如果没有注释一个新人接手这个项目至少需要一整天才能理清各层之间的关系。配套的文档部分我写了三类。第一类是需求分析文档把每个功能模块的输入、输出、处理流程描述清楚第二类是数据库设计说明书包括ER图、表结构说明、字段字典第三类是部署手册从JDK安装到Tomcat发布一步步讲。我强烈建议每一个做类似项目的同学即使不要求交文档也要把设计和实现思路记录下来。这会倒逼你把业务逻辑想清楚而不是边写边改。项目里我专门用了一个工具类OrderNoGenerator来生成订单号规则是前缀加日期再加当天序号比如PO20240520001。这个类有一点要注意如果用SimpleDateFormat加System.currentTimeMillis()来拼单号在高并发场景下可能会出现重复所以在生成代码里加了synchronized保证线程安全。虽然是课程设计级别的项目但这种细节体现的是工程素养。6. 后续演进与个人实操心得把SSH版本跑通之后如果你还有精力我建议往两个方向做演进。第一个方向是前后端分离改造保留Service层和DAO层不动把表现层的JSPStruts2替换成RESTful接口加Vue或React页面这样整个项目就变成了现代化的前后端分离架构。第二个方向是引入Maven和持续集成把手动拷jar包的方式改成pom.xml依赖管理再配合Git做版本控制项目工程化程度会高一个档次。另外我想特别提一下单元测试的价值。SSH项目的事务配置和Hibernate映射如果出了问题单靠启动Tomcat做黑盒测试定位问题很慢。我给Service层写了几个核心测试用例用SpringTest配合H2内存库跑采购单审核通过后库存增加的数量和流水记录都能在几秒内验证完毕。首次配置H2和MySQL的方言切换需要一点时间但一旦跑通后面改代码的底气就足很多。关于这个项目我还想说一点个人体会不要轻视那些看起来老的技术。我在做这个项目的过程中对Spring的IoC和AOP理解比之前用Spring Boot时深入了很多因为一切配置都是显式的你被迫搞明白每一个Bean是怎么来的。Hibernate的Session缓存机制、懒加载策略、事务边界这些概念都是在SSH这种没那么智能的框架里逐步弄清楚的。现在回到Spring Boot,遇到事务失效或者懒加载报错这类问题我就知道它底层是什么原因排查起来心里有数。这个百货中心供应链管理系统完整覆盖了JavaWeb开发的核心技术栈也覆盖了供应链业务里面最关键的采购、库存、销售闭环。如果你今年需要做类似的课程设计或毕业设计建议在跑通这个项目的基础上增加一个你自己感兴趣的功能点比如采购数据可视化分析、供应商评价或者销售预测这会成为答辩时最亮眼的加分项。本文还有配套的精品资源点击获取