企业官网建设流程全解析

简介：这是一份面向高校《数据库课程设计》的ASP.NET+SQL Server教材在线征订系统完整资源包，对应选题三“高校课程教材在线征订系统”，适合有ASP.NET/Web基础、需要完成课程设计或毕业设计的本科生参考。系统围绕教材科管理员与任课教师两类角色展开：管理员维护课程、班级和教材信息，审核教师提交的教材订购申请，并完成采购、入库、发放及状态更新；教师可提交所需教材数量并随时查看申请进度。压缩包共121个文件，体积约874KB，其中vb源码与aspx页面构成Web前端逻辑，resx、xsd、config等用于资源与配置，mdf和ldf为SQL Server数据库文件，doc报告含设计说明书与实习报告，便于整体复盘。已有1700余人学习下载，既能帮助理解在线征订系统从订单申请到发放的完整数据流，也可作为二次功能扩展或答辩讲解的参考底稿。

1. 学校教材订购系统到底解决什么问题：从状态流转说起

ASP.NET 加 SQL Server 的组合，在高校课程设计里几乎是一套“标准答案”式的技术选型，但很多同学的选题只做到了“能增删改查”，没有真正做出“业务流程”。这份学校教材订购系统的源码和报告，最值得拆的地方不是在 GridView 里绑定了一个表，而是它把教材订购的完整生命周期做了出来：任课教师提交订购申请，教材科管理员审核、采购、入库、发放，每一步都有独立的页面和对应的状态更新。也就是说，教师能看到自己的申请进度，管理员能控制哪个环节往下走，整个数据不是一口气插进去就完了，而是经过五次状态变更才真正结束。

这套系统适合两类人：一类是做数据库课程设计时选题刚好落在“订单 + 审核 + 状态”这类场景上的在校生，另一类是刚接触 ASP.NET Web Forms，想看一个完整项目怎么组织页面、存储过程、状态字段的人。后面几章我会从数据库设计、页面文件布局、状态流转、常见翻车点这几个方向逐一拆开，最后给出一套能拿去答辩演示的验证方案。

2. 先看懂系统的数据骨架：SQL Server 表结构与关联关系

2.1 表拆解：七个基础表分别存什么

这套系统虽然是课程设计，但数据表的设计并没有偷懒。从功能反推，至少要包含课程信息表、教师信息表、教材表、订购申请主表和订购明细表（也可以合并），再加上一个用户表和班级表。以最常见的做法来说，订购申请主表存整体状态，明细表或子表存具体教材名称、ISBN、单价、数量这些信息，这样设计的好处是：审核、采购、发放都只改主表的状态字段，不动明细数据，避免每次更新都要重写一整行。

创建表时有一个关键的取舍——订购申请里的教材名称、出版社、ISBN、编者、定价这几个字段，到底是从教材表里外键关联，还是直接冗余到申请表里。这个系统的做法更偏向冗余。原因很直接：教材的“当时定价”是会变的，今天订的教材定价 39.8，下学期可能调到 42.5，如果申请记录里只存了一个教材 ID，再去关联教材表，历史数据就被污染了。所以存冗余字段反而是合理的设计。你在做类似系统时（比如订单 + 商品）也可以沿用这个思路：主数据引用外键，快照数据直接冗余，双轨并行。

代码层面，这套系统用的是 SQL Server 数据库，脚本文件里包含建表语句和初始测试数据。核心的建表逻辑大致是这样：

-- 创建课程信息表 CREATE TABLE CourseInfo ( CourseID INT PRIMARY KEY IDENTITY(1,1), -- 课程编号，自增主键 CourseName NVARCHAR(50) NOT NULL, -- 课程名称 TeacherName NVARCHAR(20) NOT NULL, -- 任课教师 CollegeName NVARCHAR(50) NOT NULL, -- 所属学院 ClassName NVARCHAR(60) NOT NULL -- 学生班级 ); -- 创建教材订购申请表 CREATE TABLE BookOrderInfo ( OrderID INT PRIMARY KEY IDENTITY(1,1), -- 申请编号 CourseID INT NOT NULL, -- 关联课程表 BookName NVARCHAR(100) NOT NULL, -- 教材名称 Publisher NVARCHAR(50) NOT NULL, -- 出版社 AuthorName NVARCHAR(20) NOT NULL, -- 编者 ISBN NVARCHAR(20) NOT NULL, -- 教材ISBN Price DECIMAL(6,2) NOT NULL, -- 定价，两位小数 Quantity INT NOT NULL DEFAULT 1, -- 订购数量 OrderStatus TINYINT NOT NULL DEFAULT 0, -- 0待审核 1通过 2不通过 3采购中 4已完成 5已发放 RejectReason NVARCHAR(200) NULL, -- 审核不通过的原因 SubmitTime DATETIME NOT NULL DEFAULT GETDATE(), -- 提交时间 FOREIGN KEY (CourseID) REFERENCES CourseInfo(CourseID) );

这段 sql 里有几个设计细节值得说明。OrderStatus 用的 TINYINT 而不是 NVARCHAR，是因为状态在代码里要频繁比较，用数字比较比字符串比较稳，也省存储；RejectReason 允许为空，是因为只有审核不通过时才需要写理由；SubmitTime 用 DEFAULT GETDATE()，让数据库来打时间戳，防止程序里的时间格式不一致。

2.2 一条 JOIN 查询串起全链路数据

有了表结构，接下来最实用的就是“按教师查进度”和“按课程查申请”这两类查询。系统里教师要能看到自己提交的申请走到哪一步，管理员要能看到所有申请并按课程或班级筛选。一个通用的视图或存储过程能大幅减少页面里的重复代码。

-- 查询某任课教师提交的所有教材订购申请及当前状态 SELECT c.CourseName, c.TeacherName, c.ClassName, b.BookName, b.Publisher, b.AuthorName, b.ISBN, b.Price, b.Quantity, DATENAME(yyyy, b.SubmitTime) + '-' + REPLACE(STR(MONTH(b.SubmitTime), 2), ' ', '0') + '-' + REPLACE(STR(DAY(b.SubmitTime), 2), ' ', '0') AS SubmitDate, CASE b.OrderStatus WHEN 0 THEN N'待审核' WHEN 1 THEN N'审核通过' WHEN 2 THEN N'审核不通过' WHEN 3 THEN N'采购中' WHEN 4 THEN N'订购完成' WHEN 5 THEN N'已发放' END AS StatusText FROM BookOrderInfo b INNER JOIN CourseInfo c ON b.CourseID = c.CourseID WHERE c.TeacherName = @TeacherName ORDER BY b.SubmitTime DESC;

这里把状态数字转成中文文本这一步放在 SQL 里做，而不是放到 C# 页面再去判断，能减少代码页面的工作量——绑定 GridView 时直接显示 StatusText 这一列就行，后端少写一次循环。如果要按课程筛选某个学院的申请情况，把 WHERE 条件换成 c.CollegeName = @CollegeName 或者按 ClassName 模糊匹配都行。整个查询的核心逻辑就是通过 CourseID 外键把两张表 JOIN 起来，这是这套系统里几乎所有数据页面的基础。

2.3 数据库脚本导入的常见失败点

把 .sql 文件拿到 SQL Server Management Studio（SSMS）里执行时，经常遇到两个问题。第一个是数据库没有先创建，直接执行建表脚本会报“数据库不存在”——先在 SSMS 里新建一个名为 BookOrderDB 的数据库（名字不一定叫这个，以代码里的连接串为准），然后选中这个库再执行脚本。第二个是 SQL Server 实例的排序规则问题，中文 NVARCHAR 字段如果遇到乱码或长度不够，需要把表字段统一改成 NVARCHAR 而不是 VARCHAR，并确保创建数据库时选用 Chinese_PRC_CI_AS 排序规则。

提示：执行 SQL 脚本前先检查 USE 语句。如果你的脚本第一行没有 USE BookOrderDB，在执行前手动在 SSMS 顶部切换到目标数据库，不然表会建到 master 库里。

3. 从文件清单反推系统流程：ASP.NET Web Forms 页面职责拆解

3.1 源码包里的页面是怎么分工的

这套系统的源码文件在解压后是一组 .aspx 页面加上 .aspx.cs 代码文件，外加 Global.asax 和 Web.config。很多第一次做 ASP.NET 课程设计的人看到这么多页面会懵，其实每个页面是有明确分工的。我拿到源码后第一件事就是把页面名和功能对应起来。

从文件命名来看，new.aspx 是新增订购申请页，update1.aspx 和 update2.aspx 分别对应审核和采购/入库的状态更新，book.aspx 是教材信息管理页，load.aspx 是页面初始化或者加载数据列表用的，history1.aspx 和 2.aspx 是查询历史申请的页面。Global.asax 里处理的是应用程序级的事件，比如应用启动时初始化数据库连接、记录全局异常。这些页面和摘要里描述的功能一一对应：教师提交申请在 new.aspx，管理员审核在 update2.aspx，状态流转逻辑通过页面的 Button 点击事件触发。

在 Web Forms 里，每个 .aspx 页面都有一个同名的 .aspx.cs 文件，里面写的是 Page_Load、Button_Click 这类事件函数。页面本身只负责摆放控件（TextBox、DropDownList、GridView），真正操作数据库的逻辑全部在 .cs 文件里。这种“前台模板 + 后台逻辑”的结构虽然看起来老，但有一个天生的优点：页面和操作一一对应，课程设计文档里写“功能模块图”时非常直观。

3.2 一个典型的页面生命周期：提交订购申请

下面这段逻辑是 new.aspx.cs 里的核心操作，功能是把教师填写的教材信息插入到订购申请表。这里用的是 SqlCommand 参数化方式：

protected void btnSubmit_Click(object sender, EventArgs e) { string connStr = ConfigurationManager.ConnectionStrings["BookOrderDBConnectionString"].ConnectionString; string sql = @"INSERT INTO BookOrderInfo (CourseID, BookName, Publisher, AuthorName, ISBN, Price, Quantity, OrderStatus) VALUES (@CourseID, @BookName, @Publisher, @AuthorName, @ISBN, @Price, @Quantity, 0)"; using (SqlConnection conn = new SqlConnection(connStr)) { using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@CourseID", Convert.ToInt32(ddlCourse.SelectedValue)); cmd.Parameters.AddWithValue("@BookName", txtBookName.Text.Trim()); cmd.Parameters.AddWithValue("@Publisher", txtPublisher.Text.Trim()); cmd.Parameters.AddWithValue("@AuthorName", txtAuthor.Text.Trim()); cmd.Parameters.AddWithValue("@ISBN", txtISBN.Text.Trim()); cmd.Parameters.AddWithValue("@Price", Convert.ToDecimal(txtPrice.Text.Trim())); cmd.Parameters.AddWithValue("@Quantity", Convert.ToInt32(txtQuantity.Text.Trim())); conn.Open(); int rows = cmd.ExecuteNonQuery(); conn.Close(); if (rows > 0) { lblMessage.Text = "提交成功，请等待教材科审核。"; ClearForm(); } else { lblMessage.Text = "提交失败，请检查输入信息。"; } } } }

这段代码有几个值得抄作业的细节。第一是 AddWithValue 参数化而不是拼字符串，这能挡住 SQL 注入，也是课程设计答辩时老师必问的点；第二是 CourseID 从下拉框里取值而不是手输，避免外键约束报错，也省去记忆课程编号的麻烦；第三是状态字段只在插入时赋 0（待审核），后面所有流程都靠别的页面去更新，不在插入时做状态判断，逻辑单一。

如果要改造成新增时直接给某个课程订多本教材，做法是在页面里加一个 GridView 或 CheckBoxList 让用户勾选多本教材，后台循环执行 Insert，同时用一个父表记录订单主信息，每本教材作为子表记录插入。不过现在的源码是单本教材一次申请，作为课程设计足够用了。

3.3 审核页面的核心：更新状态并记录拒绝原因

update2.aspx 对应的是管理员审核功能，核心逻辑是更新 OrderStatus 字段。这里关键点是：审核通过时要把状态改为 1，审核不通过时改为 2 并写 RejectReason。这一段的 C# 逻辑可以看出系统对状态的处理方式：

protected void btnApprove_Click(object sender, EventArgs e) { UpdateOrderStatus(Convert.ToInt32(hfOrderID.Value), 1, null); } protected void btnReject_Click(object sender, EventArgs e) { string reason = txtRejectReason.Text.Trim(); if (string.IsNullOrEmpty(reason)) { lblMessage.Text = "审核不通过时必须填写拒绝原因"; return; } UpdateOrderStatus(Convert.ToInt32(hfOrderID.Value), 2, reason); } private void UpdateOrderStatus(int orderId, byte newStatus, string reason) { string sql = reason == null ? "UPDATE BookOrderInfo SET OrderStatus = @Status WHERE OrderID = @OrderID" : "UPDATE BookOrderInfo SET OrderStatus = @Status, RejectReason = @Reason WHERE OrderID = @OrderID"; using (SqlConnection conn = new SqlConnection(connStr)) { using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@Status", newStatus); cmd.Parameters.AddWithValue("@OrderID", orderId); if (reason != null) cmd.Parameters.AddWithValue("@Reason", reason); conn.Open(); cmd.ExecuteNonQuery(); } } }

把两个按钮的事件都收敛到一个 UpdateOrderStatus 方法里，这是一个好习惯。代码复用的同时，也避免了“审核通过但状态写成 2”这种因为复制粘贴导致的低级 bug。hfOrderID 是页面上一个 HiddenField 控件，用来在 GridView 行选中时暂存当前订单 ID，这也是 Web Forms 里常见的传值手段。

提示：如果用 Session 或 ViewState 传订单 ID，页面刷新后容易出问题；HiddenField + SelectedIndexChanged 事件是课程设计里最稳的做法。

4. 教材订购状态机：从提交到已发放的流转与权限控制

4.1 状态字段设计：为什么用数字不用字符串

这套系统的七个功能点，本质上是一条状态链：待审核 → 审核通过/不通过 → 采购中 → 订购完成 → 已发放。数据库里的 OrderStatus 字段用 0 到 5 的数字表示，这是一个典型的状态机设计。用数字而不用字符串有三个理由：一是比对比稳定，不等于“审核通过”和“审核不通过”这种中文字符串的比较不会出错；二是数据库存储空间小，TINYINT 只占 1 字节；三是扩展性强，以后如果要加“已退订”状态，加一个数字 6 就行，不用改动已有的数据。

但数字的缺点是不直观。所以查询时要用 CASE 语句把数字翻译成文字，这部分前面已经展示过。代码里也可以定义一个枚举类来对应，比如：

public enum OrderStatus { Pending = 0, // 待审核 Approved = 1, // 审核通过 Rejected = 2, // 审核不通过 Purchasing = 3, // 采购中 Completed = 4, // 订购完成 Distributed = 5 // 已发放 }

这样在代码里写 if (orderStatus == OrderStatus.Purchasing) 而不是 if (orderStatus == 3)，阅读性和维护性都会好很多，答辩时讲状态设计也能多说两句。

4.2 状态流转的控制逻辑：谁能做什么事

从流程上看，每个状态变更操作属于不同角色：教师提交申请后只能查询进度，审核、采购、入库、发放的操作都在管理员端。这套系统没有做复杂的角色权限表，而是通过页面访问控制来区分——教师用 new.aspx 和 history1.aspx，管理员用 update2.aspx 和 book.aspx。这是一种在课程设计里可以接受的简化方案。

真正容易出问题的点是状态跳转的合法性。比如一个申请还在“待审核”状态，管理员不应该能直接把它改成“已发放”。虽然从业务逻辑上讲不应该出现，但代码里如果只是写一句“UPDATE ... SET OrderStatus = 5”，就可能出现跳过中间环节的脏数据。建议在更新前做一次当前状态判断：

// 更新状态前检查当前状态是否合法 string checkSql = "SELECT OrderStatus FROM BookOrderInfo WHERE OrderID = @OrderID"; int currentStatus = 0; using (SqlCommand cmd = new SqlCommand(checkSql, conn)) { cmd.Parameters.AddWithValue("@OrderID", orderId); currentStatus = Convert.ToInt32(cmd.ExecuteScalar()); } // 只有状态为 1（审核通过）时才允许改为 3（采购中） if (currentStatus == (int)OrderStatus.Approved && newStatus == (int)OrderStatus.Purchasing) { // 执行更新 } else { lblMessage.Text = "当前状态不允许执行该操作"; }

这段代码看起来多写了几行，但它能挡住两类常见事故：一是管理员连续点两次按钮导致状态被二次更新，二是页面被恶意构造请求直接把某条记录改成已完成。课程设计里老师经常问“如果流程跳过了怎么办”，这一段就是答案。

4.3 教师查询进度：history1.aspx 的三种实现方式

查询进度是教师端唯一需要的功能。最常见的实现方式是 GridView 绑定一个 SqlDataSource，页面代码比较简单，但查询逻辑写死在 .aspx 里，不推荐。好一点的做法是后台代码绑定数据源：

protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { BindGrid(); } } private void BindGrid() { string sql = @"SELECT c.CourseName, c.TeacherName, c.ClassName, b.BookName, b.Publisher, b.Price, b.Quantity, CASE b.OrderStatus WHEN 0 THEN N'待审核' WHEN 1 THEN N'审核通过' WHEN 2 THEN N'不通过' WHEN 3 THEN N'采购中' WHEN 4 THEN N'完成' WHEN 5 THEN N'已发放' END AS StatusText FROM BookOrderInfo b INNER JOIN CourseInfo c ON b.CourseID = c.CourseID WHERE c.TeacherName = @TeacherName ORDER BY b.SubmitTime DESC"; using (SqlConnection conn = new SqlConnection(connStr)) { SqlDataAdapter da = new SqlDataAdapter(sql, conn); da.SelectCommand.Parameters.AddWithValue("@TeacherName", Session["UserName"].ToString()); DataTable dt = new DataTable(); da.Fill(dt); GridView1.DataSource = dt; GridView1.DataBind(); } }

这里的 TeacherName 取自 Session，登录时写入，查询时直接拿来过滤数据。用 Session 而不是再从页面传一次，避免了用户修改页面源码来查看别人的数据——虽然课程设计里没人真去搞，但这是一个正确的安全意识。

4.4 状态更新的“最后一步”：发放与入库

发放操作通常发生在教材到货之后。管理员把状态从 4（订购完成）改成 5（已发放）。这一步和前面的更新操作类似，但要注意一个细节：发放时往往需要记录发放时间或经手人。如果需要保存这些附加信息，就要在表里加字段，比如 AddTime 或 HandleBy。源码里如果没加，你自己扩展的时候可以直接在 SQL 语句里多加两个赋值字段，不影响已有逻辑。

5. 避坑指南：这套源码里最常见的五个翻车点

5.1 页面回发导致 GridView 数据丢失

现象：点击 GridView 里的按钮后，页面刷新，表格变空了。原因：Page_Load 里绑定了数据但没有检查 IsPostBack，每次回发都重新绑定，导致事件触发后表格重新加载，SelectedIndexChanged 里拿不到选中的行。解决：把绑数据的语句放到 Page_Load 的 if (!IsPostBack) 分支里，只有首次加载才绑定数据。

protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { BindGrid(); // 只在首次加载时绑定 } }

5.2 连接字符串写死导致换机器跑不起来

现象：在自己电脑上能跑，换个环境报“建立与 SQL Server 的连接时出错”。原因：Web.config 里连接串的服务器名写的是 localhost 或某个开发机的实例名，换到别的电脑上 SQL Server 实例名不一样。解决：把连接串里的 Data Source 改成 .\SQLEXPRESS 或 (local)，并确保 SQL Server 允许 SQL 身份验证或 Windows 身份验证。

<connectionStrings> <add name="BookOrderDBConnectionString" connectionString="Data Source=(local);Initial Catalog=BookOrderDB;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>

5.3 状态值用字符串比较导致中英文不匹配

现象：明明状态是“审核通过”，代码里 if (status == "审核通过") 却进不去。原因：数据库里存的是数字，页面显示的是 CASE 转换后的中文，拿转换后的显示文本和常量比较自然匹配不上。解决：代码里全部用数字或枚举比较，只有 SQL 层做显示转换。

5.4 修改 GridView 数据后再次绑定导致编辑失效

现象：点“编辑”进入编辑模式，修改一行数据点“更新”，数据没变化。原因：EditIndex 在回发后没有被重新设置，或者更新后没有重新绑定 GridView。解决：在 RowUpdating 事件里执行 UPDATE 语句后，把 GridView 的 EditIndex 设回 -1，然后重新调用 BindGrid()。

protected void GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e) { int orderId = Convert.ToInt32(GridView1.DataKeys[e.RowIndex].Value); string newStatus = ((DropDownList)GridView1.Rows[e.RowIndex].FindControl("ddlStatus")).SelectedValue; // 执行 UPDATE 语句... GridView1.EditIndex = -1; BindGrid(); }

5.5 教材订购数量与库存数量对不上

现象：教材预订了 200 本，到货 180 本，系统里没有记录，发放时数量对不上。原因：表里只有 Quantity（订购数量）字段，没有实收数量或发放记录。解决：在 BookOrderInfo 表里增加 ArrivedQuantity 字段，到货时更新这个字段，发放时以实收数量为准。这个坑在验收演示时特别容易被问住，提前补上会主动很多。

6. 把课程设计升级成答辩能讲的 Demo：验证流程与三个加分项

拿到源码后不要急着打包交作业，先按业务逻辑把整套流程跑一遍。我一般会用以下这套验证路径来确认系统是通的：用教师账号登录 → 提交一条新教材订购申请 → 检查状态为“待审核” → 用管理员账号登录 → 在审核页面看到这条申请 → 点击通过 → 状态变为“审核通过” → 继续操作更新状态为“采购中” → 再更新为“订购完成” → 最后更新为“已发放” → 再回到教师账号查询，确认可以查到这条申请并且状态已同步。这整个流程如果都能走通，系统主链路就是完整的，答辩时照着讲一遍就够了。

三个加分项分别说。第一，在验证状态流转时准备一条“审核不通过”的数据，展示拒绝原因如何传给教师端，因为这能证明你不是只有单一流程，还有分支处理。第二，把数据库脚本里的测试数据改成你们学校自己的课程和班级名称（用代称也可以，关键是要贴合你报告里的场景描述），演示时老师会觉得你是真正理解这套系统的。第三，在报告里画一张状态流转图，把“待审核 → 审核通过 → 采购中 → 订购完成 → 已发放”和“审核不通过 → 终止”画清楚，这是数据库设计说明里最直观的加分内容。

关于代码里的一个小习惯，我每次拿到这类源码都会先做两件事：第一步是全局搜索 Response.Write，把调试用的输出清理掉；第二步是把所有 SQL 语句统一改成参数化，顺手把连接串从代码里挪到 Web.config。这两步做完，项目基本从“能跑的课程设计”变成“像样的课程设计”。当时我从一个学长手里拿到这套系统的第一版源码时，也是先跑通了全流程，再对着状态字段做了半天边界测试，后来每次做课设都强制自己走一遍这套验证流程，从那以后交出去的东西再没被老师打过回票。希望这份拆解能帮你把教材订购系统真正跑起来，不只是解压看一眼就搁置，而是能在答辩台上把每一步讲清楚。

本文还有配套的精品资源，点击获取