MXH814 GitHub avatar

steam-platform-db-course-design

MXH814

一个基于C#/.NET、Oracle和Vue 3开发的类Steam数字游戏平台课程设计项目，重点突出数据库设计、事务一致性和团队协作。

Stars

9

7 天增长

暂无数据

Fork 数

1

开放 Issue

0

开源协议

暂无数据

最近更新

2026-07-23

AI 仓库情报摘要
FR-AI / ANALYSIS

为什么值得关注

该项目具备高度结构化的工程实践，强制执行严格的数据库约束、五层后端架构以及完整的业务流程（购买、退款、市场交易、成就），为数据库课程设计提供了优秀的示范参考。

适合谁使用

  • 计算机专业学生（数据库课程设计）
  • 教育工作者（作为综合教学案例）
  • 自学全栈开发者（学习C#/.NET与Oracle集成）
  • 后端开发者（了解企业管理协作规范）

典型使用场景

  • 学习关系数据库设计（27张表、第三范式、约束）
  • 实践C#/.NET Web API与Oracle数据访问
  • 模拟游戏商店：钱包、订单、市场撮合、退款
  • 体验团队协作开发：Git分支、Pull Request、文档同步

项目优势

  • 完整的数据库模式：27张表、40个外键、13个唯一约束、222个检查约束
  • 清晰的分层架构（Controller、Application、Domain、Infrastructure、Shared），依赖严格受控
  • 详细的团队分工与各组交付规范
  • 涵盖幂等、并发、原子性的核心业务事务处理

使用前须知

  • 仅作课程设计演示，非生产级系统
  • 技术栈固定（C#/.NET、Oracle、Vue 3），灵活性有限
  • 使用模拟数据，不与Steam实时同步

README 快速开始

"Steam-" 数字游戏平台系统课程设计 README

本 README 是项目后续设计、开发、部署、验收和答辩的统一参考文件。
任何技术选型、部署方案、数据库结构、开发计划、实际实现与本文档不一致时，必须先更新 README，再继续开发。

协作铁律：普通组员禁止直接推送 main

main 分支是项目稳定主线，必须始终保持可运行、可演示、可用于答辩。

普通组员开发功能时必须遵守以下流程：

从 main 拉取最新代码
  -> 创建自己的功能分支
  -> 在功能分支提交代码
  -> 推送功能分支到 GitHub
  -> 发起 Pull Request
  -> 由总负责人检查代码、接口、数据库脚本、README 和演示流程
  -> 通过后合并进 main

GitHub 仓库已对 main 分支启用保护规则：

  • 普通组员禁止直接 push 到 main。
  • 禁止 force push。
  • 禁止删除 main。
  • 普通组员合并前必须通过 Pull Request。
  • 普通组员 Pull Request 至少需要 1 个 review。
  • Pull Request 中未解决的讨论必须先处理完。
  • 总负责人马祥珲本人，或经马祥珲明确授权由 Codex 完成且已通过构建/测试/安全检查的提交，可以由管理员直接合并到 main，不需要等待 Pull Request 审批。
  • 其他组员提交的业务代码仍必须走 Pull Request 审查流程。

任何数据库表结构、公共接口、统一响应格式、技术路线、部署方案、团队分工和交付规范变更，都必须在 Pull Request 中同步更新 README。

技术路线和分工属于总负责人统一管理的项目级决策：

  • 组员不能在功能 PR 中自行修改技术路线、系统架构、团队分工、模块边界和交付规范。
  • 未经马祥珲明确确认，不得把 C# / .NET / Oracle / B/S、五层结构、前端技术方向、组别职责或总负责人规则改掉。
  • 未经马祥珲明确确认，不得更换最终样板游戏。当前最终样板游戏固定为 Counter-Strike 2 和 Don't Starve Together / 饥荒联机版。
  • 如果确实认为既定方案需要调整，必须先提出单独讨论，不得夹带在功能代码 PR 中直接改 README。

1. 最高约束：课程提纲

本项目必须严格遵守 2026《数据库课程设计》课程提纲.doc 的要求。

课程提纲中的关键硬要求：

  • 使用 VS.NET 较新版本。
  • 使用 C# 语言。
  • 使用 Oracle 18c 或更高版本作为 DBMS。
  • 使用 Oracle 数据访问组件或 ORM 框架。
  • 开发一个实用的信息管理系统。
  • C/S 或 B/S 均可。
  • 至少 12 张表，且符合第三范式。
  • 至少 20 个功能点，其中至少 15 个功能点必须具有一定业务逻辑，不能只是表的增删改查。
  • 编码实现课程项目，并进行测试，部署或生成可执行程序。
  • 撰写系统需求分析文档、系统设计与实现文档、答辩 PPT。
  • 评分关注工作量、应用性、复杂性、总体设计、功能完整性、数据库合理性、界面美观、编码规范、鲁棒性、扩展性、文档质量和答辩表现。

本项目额外确定的约束：

  • 架构选择 B/S。
  • 除前端界面外，后端、应用服务器、数据访问层、部署脚本等项目实现均使用 C# / .NET 技术栈。
  • 数据库和应用服务器均部署到腾讯云云服务器。
  • 前端继续使用 Vue 技术栈实现 Steam 风格界面。

废弃旧计划：

  • 不再使用 Spring Boot。
  • 不再使用 Java 作为后端语言。
  • 不再使用 Maven 作为项目构建主线。
  • 不再使用 MyBatis / MyBatis-Plus。
  • 不再使用 Tomcat / HikariCP / Spring Security。

2. 当前项目定位

本项目实现一个类似 Steam 的数字游戏平台系统。系统不仅要完成基础游戏商店功能，还要体现数据库课程设计重点：关系模型、约束、事务、一致性、日志、审计、幂等、防并发、资产确权和复杂业务流程。

核心业务域：

  • 玩家账号与权限。
  • 开发商与管理员。
  • 游戏商店与公告。
  • 钱包账户与资金流水。
  • 游戏订单、订单明细、支付流水、订单状态日志。
  • 退款申请、退款明细、退款审核日志。
  • 玩家游戏库与数字资产确权。
  • CDKey 批次、CDKey、兑换风控日志。
  • 游戏评价主记录与评价历史版本。
  • 成就字典与玩家成就解锁。
  • 饰品模板、饰品实例、玩家库存。
  • 饰品市场买卖挂单、撮合成交、资金清算、饰品流转账本。

2.1 最终样板游戏与统一业务口径

本项目最终只选用两款真实 Steam 游戏作为公开演示和测试数据口径：

游戏Steam AppID项目内定位主要承载模块
Counter-Strike 2730饰品经济、库存、市场交易、热门免费游戏样板饰品模板、饰品实例、库存、市场卖单/买单、成交、价格历史、Steam 风格详情页
Don't Starve Together / 饥荒联机版322330买断制联机生存、DLC/皮肤箱、创意工坊、社区样板游戏购买、游戏库、DLC/礼包、评价、公告、创意工坊入口、社区讨论、成就模拟

选择依据：

  • Counter-Strike 2 Stea