ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

SSM+Vue农业大数据养猪平台管理系统:毕设选题、实现与答辩全指南

SSM+Vue农业大数据养猪平台管理系统:毕设选题、实现与答辩全指南 每年到了毕设选题季总有人跑来问我同一个问题“SSM的项目那么多图书管理、宿舍报修、网盘系统全被做烂了怎么选题才能不撞车还能拿高分”我的回答始终没变过——技术栈从来不是瓶颈瓶颈在于你把这些技术往什么场景里放。同样是SpringSpringMVCMyBatis别人做通用管理系统你把它落到农业大数据养猪平台管理系统里整个项目的立意、数据量级和工程复杂度立刻就不一样了。这个选题去年我带过两届本科生完整跑通过一遍从需求分析到数据库建模从后端接口到Vue前端再到论文和答辩整套链路都摸得很透。今天就把这套系统的设计思路、核心实现、踩坑经历和答辩建议一次性写清楚不管你是打算直接拿这个题目做毕设还是想在里面换个养殖品类做改造这篇文章都能帮你省下大量查资料和试错的时间。1. 选题逻辑与项目定位为什么“养猪”反而是毕设的加分项1.1 农业大数据赛道毕设选题的“蓝海”先聊一个现实问题大部分本科毕设管理系统都停留在“增删改查”层面老师看多了自然审美疲劳。而农业大数据是近年来政策层面和产业层面都在推的方向把它作为系统标题第一眼就能让答辩老师觉得“这学生关注到了真实产业问题”而不是拍脑袋凑了个题目。这里有个核心逻辑要摆正毕设最怕的不是技术太难而是技术方向和业务场景脱节。养猪行业恰好是农业大数据最适合落地的场景之一——它有清晰的实体对象猪只、猪舍、批次、连续产生的时间序列数据日增重、采食量、体温、明确的业务痛点疾病预警、饲料转化率分析、死亡率统计每一样都能在系统里找到对应的功能落点。现实中的规模猪场一头母猪一年产仔二十多头一个千头猪场每天产生的饲喂记录、健康检查记录、环境温湿度记录动辄上百条。这些数据如果只靠Excel和纸质台账管理成本极高。这套系统的价值就在于把散落的数据收拢起来变成可查询、可统计、可预警的决策依据。对毕设而言这意味着你要处理的数据体量和业务规则足够写出一篇内容充实的论文。1.2 从业务复杂度看系统价值再说直白点毕设选题要满足三个条件工作量够、技术点够、故事够。养猪平台管理系统在这三件事上天然占优工作量够完整的系统至少包含猪只档案、猪舍管理、批次管理、饲喂记录、免疫管理、疾病管理、销售出栏、预警提醒、统计报表九大模块每个模块都有独立的业务逻辑不是简单的十几个页面凑数。技术点够后端SSM框架做接口和业务层前端Vue做SPA应用数据库涉及多表关联和聚合统计可视化用ECharts展示生长曲线和栏舍利用率再加上权限控制、文件上传、定时预警技术栈覆盖非常完整。故事够答辩的时候你可以讲清楚“为什么要做这个系统”——传统养猪管理效率低、数据难追溯、疫情风险高这套系统通过数字化手段解决这些问题选题意义这段直接可以写满两页论文。另外提醒一句如果担心“养猪”这个具体场景在答辩时被老师追问产业背景你可以把系统定位稍微拔高一点把它定义成“农业大数据在畜牧养殖领域的应用示范”这样既保留了具体的业务载体又有了行业宏观价值。我在论文摘要里就是这么处理的效果很好。2. 技术选型决策记录SSM与Vue前后端分离的取舍依据2.1 为什么还在用SSM而不是Spring Boot这个题目的标题直接锁定了SSM也就是Spring SpringMVC MyBatis很多学生第一反应是“这都什么年代了还用SSM”。说句掏心窝的话如果你是做毕业设计而不是公司生产项目SSM不仅不过时反而有它独特的优势。核心原因有三点原理考查友好Spring Boot把大量配置自动化了答辩时老师一句“说说自动装配原理”就能问住很多人。SSM的配置是手写的你把web.xml、spring-mvc.xml、mybatis-config.xml挨个讲一遍老师就知道你是真懂框架底层而不是只会用脚手架。工作量展示充分SSM的配置文件、依赖管理和代码结构比Spring Boot更“原生态”体现在论文里就是更多的配置说明和更完整的系统设计章节。很多老师的评分标准里这部分占分并不低。兼容性稳SSM搭配JSP或前后端分离都很成熟遇上JDK版本、Tomcat版本的各种组合基本不会翻车。我实测过JDK 1.8 Tomcat 8.5 MySQL 5.7这套组合稳如老狗。我建议项目采用前后端分离的SSM架构后端只提供RESTful API前端Vue独立开发后打包成静态文件可以部署在同一Tomcat下也可以分开部署。相比传统的SSMJSP前后端分离更适合作为毕设展示也方便你在论文里单独写“前端设计”和“后端设计”两章。2.2 前端为什么选Vue Element UIVue目前是国内外前端三大框架里中文资料最全、上手门槛最低的对毕设来说这是决定性优势。踩坑的时候你能在中文社区找到大量现成答案这在答辩前一两周的冲刺阶段能救命。具体到技术版本我给你的建议是技术项推荐选型理由Vue版本Vue 2 Element UI资料最多、组件最全Element UI对表格和表单的封装非常成熟适合管理类系统快速出效果HTTP库Axios统一处理请求拦截和响应拦截方便统一加token和错误提示路由Vue RouterSPA页面跳转配合侧边栏菜单实现动态路由可视化ECharts图表类型全中文文档友好社区案例覆盖各种场景如生长曲线、饼图、柱状图状态管理Vuex虽然毕设体量不一定用得上但写上对论文“技术选型”章节有利有些人会推荐Vue 3 Element Plus如果你本来就会Vue 3用新版也没问题。但如果你是临时学前端Vue 2 Element UI的学习成本明显更低很多老教程直接照着敲就行不用反复适配版本差异。2.3 可视化与数据存储的配套选型后端持久层我用的是MySQL 5.7理由很朴素这是教学和毕设场景下最普及的版本Navicat、SQLyog这些工具兼容都没问题。MySQL 8.0也能用但注意8.0的驱动类名和时区配置略有差异MyBatis连接串要写成com.mysql.cj.jdbc.Driver别拿5.7的配置硬套。可视化部分除了ECharts还有一个值得加分的组件叫数据大屏。用一个全屏页面把栏舍数量、当前存栏量、今日出生数、死亡数、饲料消耗趋势这些核心指标用图表铺出来答辩演示的时候第一个打开它视觉冲击力非常强。这个页面本质上就是几个ECharts图表加一个轮播接口工作量不大但极其出效果。文件存储方面猪只照片、免疫凭证这些上传文件直接存本地磁盘就行不要为了毕设去接OSS。在配置文件里写一个上传路径常量用一个upload目录统一管理简单可靠。答辩时老师问“文件存在哪”你就说“独立静态资源目录”完全可以自圆其说。3. 需求分析与功能模块设计猪场到底需要一套什么系统3.1 用户角色与权限边界做任何管理系统第一件事不是建表而是把用户角色理清楚。养猪平台的用户我建议设三类分别对应猪场的真实岗位系统管理员负责用户管理、猪舍信息维护、基础数据字典配置权限最高。养殖技术员负责猪只档案录入、饲喂记录、健康检查、疫苗接种是业务数据的主要生产者。管理决策者场长只读权限主要看统计报表和数据大屏用于掌握全场运营状况。权限这块别整太复杂的RBAC一个角色表加一个用户角色字段就够了。用户表里存role字段后端拦截器判断一下当前登录用户的角色即可放行或拒绝。SpringMVC拦截器在HandlerInterceptor里配置这部分写进论文能体现你对访问控制的理解。3.2 核心业务模块清单需求分析阶段我建议把系统拆成以下模块这个清单可以直接作为论文里功能结构图的底稿猪舍管理维护猪舍编号、名称、类型配怀舍、产房、保育舍、育肥舍、容量。批次管理按进场批次或周次对猪只分组批次关联猪舍、品种、来源。猪只档案管理每头猪一个档案包含耳标编号、性别、品种、出生日期、父本母本、所在猪舍/批次、状态在养/出栏/死亡。饲喂记录按批次或猪舍记录饲料品种、投喂量、日期、操作人。免疫/疫苗管理记录疫苗名称、接种日期、下次接种日期、接种头数。疾病与健康管理记录疾病诊断、用药情况、处理结果支持按疾病类型统计发病率。销售出栏管理记录出栏日期、重量、单价、买家信息自动更新猪只状态。预警提醒到期未接种疫苗提醒、环境参数超限提醒、母猪预产期提醒。数据统计分析存栏量统计、月度出生/死亡/出栏统计、饲料转化率分析、疾病类型分布。系统管理用户管理、密码修改、数据字典。这里有一个容易被忽略的细节预警模块能否真正触发取决于业务数据是否按时录入。所以你在设计表单的时候凡是涉及日期字段都要跟当前时间做一次比对。后面第5节我详细讲实现方式。3.3 预警与大数据分析区分“演示功能”和“实用功能”做毕设很容易犯的毛病是每个模块都想做深最后哪个都做不透。我当初的取舍原则是核心功能做到能实际运行扩展功能做到能演示闭环。什么叫能实际运行猪只档案的增删改查、分页搜索、关联查询必须完全跑通这是系统立足之本。什么叫能演示闭环比如“饲料转化率分析”FCR 饲料消耗总量 / 总增重你要让这个指标真的从数据库里算出来而不是写死一个假数据。用SQL的SUM和GROUP BY按批次聚合再结合猪只的体重变化记录计算增重链路是通的可演示的就足够了。预警功能属于典型的“能演示闭环”功能。真实猪场的预警需要对接物联网传感器毕设做不到但你可以模拟数据入库手动录入猪舍温湿度超过阈值就在预警列表生成一条记录。这个逻辑是真的只是数据来源从“传感器自动上报”变成了“人工录入”这个差异在论文里明确写出来反而显得你想得周全。4. 数据库建模与核心表结构设计4.1 整体ER思路数据库设计是论文评分的重头戏也是后期开发返工与否的关键。我给这套系统设计了9张核心表整体关系用一个“批次”字段把猪只和猪舍串联起来猪舍拥有多个批次批次包含多只猪猪只关联多条饲喂、健康、销售记录。这个设计的好处是兼顾了个体管理和批次统计两个维度。既要能查“某头猪的完整履历”也要能算“某批次的平均日增重”。如果只按批次建表不考虑个体没法支撑“一头猪一张档案”的展示需求如果只按个体建表统计查询性能会很难受。二者结合是猪场场景下最合理的折中。4.2 核心建表SQL下面给出几张关键表的建表SQL我直接用了实际项目中验证过的字段设计。注意统一使用utf8mb4字符集不然存中文和特殊符号容易出乱码。CREATE DATABASE pig_farm DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE pig_farm; -- 用户表 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT 密码建议MD5加密存储, real_name VARCHAR(50) COMMENT 姓名, role INT DEFAULT 2 COMMENT 1管理员 2技术员 3场长, phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 系统用户表; -- 猪舍表 CREATE TABLE pigsty ( id INT PRIMARY KEY AUTO_INCREMENT, sty_no VARCHAR(30) NOT NULL COMMENT 猪舍编号, sty_name VARCHAR(50) COMMENT 猪舍名称, sty_type VARCHAR(20) COMMENT 配怀舍/产房/保育舍/育肥舍, capacity INT COMMENT 设计容量, remark VARCHAR(200) ) COMMENT 猪舍信息表; -- 批次表 CREATE TABLE pig_batch ( id INT PRIMARY KEY AUTO_INCREMENT, batch_no VARCHAR(30) NOT NULL COMMENT 批次编号, sty_id INT COMMENT 所在猪舍ID, breed VARCHAR(30) COMMENT 品种, source VARCHAR(100) COMMENT 来源, in_date DATE COMMENT 进场日期, quantity INT COMMENT 批次数量, status INT DEFAULT 0 COMMENT 0饲养中 1已出栏, FOREIGN KEY (sty_id) REFERENCES pigsty(id) ) COMMENT 批次表; -- 猪只档案表 CREATE TABLE pig_info ( id INT PRIMARY KEY AUTO_INCREMENT, ear_tag VARCHAR(30) NOT NULL UNIQUE COMMENT 耳标编号, batch_id INT COMMENT 所属批次ID, sty_id INT COMMENT 所在猪舍ID, gender TINYINT COMMENT 0公 1母, breed VARCHAR(30), birth_date DATE, weight DECIMAL(8,2) COMMENT 当前体重kg, status INT DEFAULT 0 COMMENT 0在养 1出栏 2死亡, remark VARCHAR(200), FOREIGN KEY (batch_id) REFERENCES pig_batch(id), FOREIGN KEY (sty_id) REFERENCES pigsty(id) ) COMMENT 猪只档案表; -- 饲喂记录表 CREATE TABLE feed_record ( id INT PRIMARY KEY AUTO_INCREMENT, batch_id INT COMMENT 批次ID, feed_type VARCHAR(30) COMMENT 饲料品种, feed_weight DECIMAL(10,2) COMMENT 投喂量kg, feed_date DATE, operator VARCHAR(50), FOREIGN KEY (batch_id) REFERENCES pig_batch(id) ) COMMENT 饲喂记录表; -- 免疫记录表 CREATE TABLE vaccine_record ( id INT PRIMARY KEY AUTO_INCREMENT, pig_id INT COMMENT 猪只ID可按批次时为NULL, batch_id INT, vaccine_name VARCHAR(50), vaccinate_date DATE, next_date DATE COMMENT 下次接种日期, operator VARCHAR(50), FOREIGN KEY (pig_id) REFERENCES pig_info(id) ) COMMENT 免疫记录表; -- 预警记录表 CREATE TABLE warning_record ( id INT PRIMARY KEY AUTO_INCREMENT, warning_type VARCHAR(30) COMMENT 预警类型, content VARCHAR(200), status INT DEFAULT 0 COMMENT 0未处理 1已处理, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 预警记录表;4.3 几个容易忽略的字段设计细节第一耳标编号必须有唯一约束。耳标相当于猪的身份证业务查询大量依赖它没有唯一索引后面查重会非常痛苦。实际猪场用的是RFID耳标毕设里用一个字符串字段模拟即可但唯一约束必须加。第二金额和重量必须用DECIMAL而不是FLOAT。这是新手最容易踩的坑。FLOAT是近似值做销售金额统计时会出现0.10.2不等于0.3的浮点误差答辩时若被老师拿数据质问会很尴尬。DECIMAL(10,2)精确到分稳妥。第三所有业务表都加create_time字段。看似多此一举但等你做统计报表“按月统计新增存栏”的时候它直接决定你能不能按时间维度聚合。当初我就是在前期没加后期补了全表那滋味不好受。还有就是逻辑删除字段deleted和状态字段status分开设计别为了省事把“删除”和“状态”混在一个字段里会有二义性。5. 关键功能实现细节从后端接口到前端可视化5.1 猪只档案分页查询的后端实现猪只档案是整个系统的核心业务设计上必须支持组合条件查询按耳标、批次、品种、状态、日期范围筛选再加分页。后端Controller用一个统一的查询条件对象接收参数分页插件我推荐MyBatis的PageHelper几行代码就搞定物理分页。RestController RequestMapping(/api/pig) public class PigInfoController { Autowired private PigInfoService pigInfoService; GetMapping(/page) public Result page(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) String earTag, RequestParam(required false) Integer status, RequestParam(required false) Integer batchId) { PageHelper.startPage(pageNum, pageSize); ListPigInfoVO list pigInfoService.queryByCondition(earTag, status, batchId); PageInfoPigInfoVO pageInfo new PageInfo(list); return Result.success(pageInfo); } }这里我想强调两个实战问题。第一个是PageHelper的使用规范它必须在查询前一行调用原理是基于MyBatis拦截器在Executor执行前改写SQL。如果你在startPage和查询之间夹了其他数据库操作分页就会错乱。第二个是返回结构统一所有接口统一返回Result对象包含code、message、data三个字段前端Axios响应拦截器里统一判断code省掉每个页面重复写错误处理的代码。MyBatis的MapperXML里动态条件用where标签配合if判断别手动拼接SQL字符串既不安全又不优雅。查询结果如果需要猪舍名称和批次号用resultMap做关联映射或写VO类接收联表查询结果推荐后者SQL简单直观。5.2 生长曲线与FCR分析的可视化实现数据可视化是“农业大数据”这个标题的关键佐证。我做了两个图表页面一个是个体猪只体重变化曲线一个是批次饲料转化率对比柱状图。个体生长曲线的数据来源是猪只的体重记录表也就是说你在每头猪的档案里增加一条历史体重记录前端用ECharts折线图展示。Vue组件里这样写template div refgrowthChart stylewidth: 100%; height: 400px;/div /template script import * as echarts from echarts export default { name: GrowthChart, props: { weightRecords: { type: Array, default: () [] } }, data() { return { chart: null } }, watch: { weightRecords: { handler() { this.renderChart() }, deep: true } }, mounted() { this.chart echarts.init(this.$refs.growthChart) this.renderChart() }, methods: { renderChart() { if (!this.chart) return const dates this.weightRecords.map(item item.recordDate) const weights this.weightRecords.map(item item.weight) this.chart.setOption({ title: { text: 体重增长曲线 }, tooltip: { trigger: axis }, xAxis: { type: category, data: dates }, yAxis: { type: value, name: 体重(kg) }, series: [{ type: line, data: weights, smooth: true, areaStyle: { opacity: 0.1 } }] }) } }, beforeDestroy() { if (this.chart) { this.chart.dispose() } } } /script两个经验要分享。第一ECharts实例必须在mounted之后初始化因为$refs要等DOM渲染完才能拿到。第二组件销毁时调用dispose()释放实例否则页面频繁切换路由会导致内存泄漏出现图表卡顿。别问我怎么知道的都是踩出来的。FCR分析的SQL逻辑是这样按批次分组求和饲料总量再按批次关联猪只的初始体重和出栏体重计算总增重最后算比值。这个SQL在MySQL里写一个LEFT JOIN加GROUP BY大概十几行就能完成。关键指标算出来之后用柱状图按批次展示FCR数值哪个批次饲料转化效率高一眼就看出来了。5.3 预警提醒的触发机制预警模块要有真实感我做了三种触发方式登录后主动检查用户登录成功后端根据当前日期扫描疫苗表如果next_date距今7天内且该批次尚未接种插入预警记录。环境数据模拟触发在猪舍环境页面录入温湿度后端比较配置的阈值范围超限即插入预警。手动新增管理人员发现问题可手工添加预警。第一种和第二种的实际代码都不复杂后端Service里写一个scanAndGenerateWarning()方法登录成功后调用查询符合条件的记录循环插入。这里要注意幂等性同一天同一头猪的同一预警不要重复插入判断条件加上“今天是否已经生成过该类型预警”的查重逻辑。不然用户每天登录刷出一堆重复提醒观感很差答辩演示也容易露怯。预警列表按未处理/已处理用状态字段区分处理操作就是一个简单的UPDATE状态位。整个功能模块虽然代码量不大但在答辩的时候你可以把这个业务闭环讲成一个故事录入猪舍温度→超限→生成预警→技术员处理→更新状态。有前因后果有数据变化这是最能打动老师的演示流程。6. 前后端联调与部署踩坑排查全过程6.1 跨域问题的完整排查链路毕设前后端分离开发时前端跑在8080端口后端跑在8081端口浏览器一请求就报跨域。这个问题的完整排查链路我梳理一遍遇到报错时按顺序查第一步先确认后端有没有加跨域配置。SpringMVC里最省事的做法是写一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8080) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }第二步检查请求是否先出了OPTIONS预检。浏览器对非简单请求会先发OPTIONS如果后端没处理或拦截器在预检请求时返回了401那就直接跨域失败。这时候去SpringMVC拦截器里排除OPTIONS请求给它放行。第三步确认Nginx或Tomcat反向代理配置没问题。如果前端部署后通过Nginx转发/api路径到后端注意proxy_pass后面的斜杠问题location /api/ { proxy_pass http://localhost:8081/; }这种写法会把路径前缀剥掉跟后端Controller的路由不匹配时会报404很容易被误判成跨域。6.2 日期格式与JSON序列化的坑Vue前端传日期字符串给后端SpringMVC默认的JSON反序列化经常报格式错误。这个坑几乎每个学生都会踩。你需要在Jackson配置里统一指定日期格式Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder - { builder.serializers(new LocalDateTimeSerializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); builder.deserializers(new LocalDateTimeDeserializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; } }另一个相关的坑是MySQL时区问题。JDBC连接串里最好显式加上serverTimezoneAsia/Shanghai否则从库里查出来的时间可能比实际时间差8个小时。这个问题很隐蔽因为有时候只在特定环境才出现排查起来非常浪费时间。6.3 MyBatis字段映射与分页插件的坑数据库字段用下划线命名如ear_tagJava实体字段用驼峰命名如earTagMyBatis默认不自动映射结果就是查出来全是null。解决办法在mybatis-config.xml里开启驼峰映射settings setting namemapUnderscoreToCamelCase valuetrue/ /settings这个配置我强烈建议建项目的时候就写上不然等到联调阶段才发现所有字段都是null定位起来非常崩溃。另外如果你用了PageHelper记得引入的版本要和MyBatis版本匹配我遇到过PageHelper 5.x搭配MyBatis 3.4版本过低导致分页失效的情况升级MyBatis版本后解决。解决办法就是分页后立即转成PageInfo对象然后马上调用PageHelper.clearPage()防止分页条件被下一次查询误用。6.4 打包部署的注意事项前端打包npm run build生成dist目录把dist里的静态文件拷贝到后端项目的webapp目录下整体打成war包部署到Tomcat。这种情况下有一个关键字要注意Vue Router如果用history模式刷新页面会404因为Tomcat找不到前端的路由路径。解决办法是改hash模式或者写一个Tomcat的WEB-INF/web.xml里配置error-page跳转。毕设建议直接用hash模式省心又稳妥。后端打包Maven执行clean package确保依赖都打进去。如果你用的Tomcat版本和本地JDK不一致启动时容易莫名其妙报错我实测的黄金组合是JDK 1.8 Maven 3.6 Tomcat 8.5 MySQL 5.7整个项目从开发到部署零意外。别盲目追求高版本稳定完工才是毕设的首要目标。7. 论文撰写与答辩准备的实战经验7.1 论文结构怎么安排这篇论文的写作顺序我建议按“背景→技术→设计→实现→测试→总结”六段式但每章都要扣住系统和数据。这里穿插一个重要建议论文里的截图不要用假数据答辩前用系统实际操作一遍把真实数据截图放进论文。老师会随机翻到某个截图问你“这个功能在哪”你要是拿假数据现场演示对不上就尴尬了。需求分析章重点写你从猪场业务里提炼出的功能需求和非功能需求配一张用例图系统设计章重点画系统架构图、功能模块图和数据库ER图系统实现章按模块逐个贴核心代码和运行截图。论文页数控制在60到80页之间重点突出“农业大数据”下的数据统计和分析功能这部分是整篇论文的最大亮点。7.2 答辩演示的节奏控制演示环节我建议按这条路线走时间控制在8到10分钟先登录展示数据大屏一眼看全场然后查一头猪的档案展示它的生长曲线接着录一条超出正常范围的猪舍温度演示预警生成和处理最后打开统计报表展示按月存栏量和饲料转化率。这条线从宏观到微观、从录入到分析把系统的每个核心亮点都串起来了。演示前一定要准备一份干净的演示数据。我在答辩前干过一件蠢事为了测试各种边界情况数据库里堆满了垃圾数据导致大屏上的图表比例很奇怪。后来我重新清理了数据库按一套完整的故事线造数据3个猪舍、2个批次、20头猪、每天都有饲喂和体重记录。这套数据完美支撑了整个演示流程。7.3 老师最爱问的几个问题根据我带毕设的经验答辩老师面对这个题目大概率会问这几个方向的问题提前准备好答案“你的大数据体现在哪里”回答要点系统实现了养殖数据的采集、存储、分析和可视化形成从数据到决策的闭环具体体现在日增重计算、饲料转化率分析、疾病发病率统计和预警机制上。别硬说自己用了Hadoop、Spark那是给自己挖坑。“SSM和Spring Boot的区别是什么”回答要点SSM是Spring、SpringMVC、MyBatis三个框架的整合需要手动维护大量XML配置更能体现底层原理Spring Boot基于约定大于配置内嵌Tomcat自动装配依赖开发效率更高。你能把两者区别讲清楚这个基础分就拿到了。“如果让你接入物联网传感器系统需要怎么改”回答要点在环境监测模块增加一个数据接收入口采用MQTT协议接收传感器上报的温湿度数据替换现在的人工录入预警判断逻辑可以复用。你只要能说出MQTT协议和现有的预警逻辑可以复用老师就知道你对系统扩展性有思考。“系统的安全性怎么保证”回答要点密码MD5加盐存储、登录拦截器校验、角色权限控制、SQL采用参数化查询防止注入。这四个点每个展开讲一两句安全这块就没问题了。最后再分享一个压箱底的经验答辩前一天把整个系统按照演示流程从头到尾走三遍。把所有会用到账号密码、测试数据、图表页面的路径都写在纸上贴在电脑旁边。真到了答辩现场紧张是必然的但只要你手指比脑子更熟悉操作路径这套系统就能稳稳演示下来。我见过太多学生项目做得不错结果答辩时因为忘密码、点错页面、图表没加载出来这些低级失误被扣了分实在可惜。只要你把系统做扎实、把演示流程跑顺这个题目拿个优秀评级完全是有把握的。
返回列表