ASP.NET点餐系统实战：WebForm三层架构与购物车设计全解析

作为一个在 .NET 这条路上摸爬滚打多年的老程序员，我一直觉得，书本上的语法和实际跑起来的系统之间，隔着一条需要自己动手去填的沟。ASP.NET 点餐系统这个项目，就是我当初用来填沟的“土方工程”之一。它不是那种高大上的微服务架构，也没有复杂的分布式中间件，但它把 WebForm 时代 ASP.NET 的核心机制、三层架构思想、数据库交互、以及前端联调这些硬骨头，全部实打实地串了一遍。

这篇文章，我想把这三周从零开始做点餐系统的完整过程，包括踩过的坑、绕过的弯、以及最终跑通时的细节，原原本本分享出来。如果你正准备用 ASP.NET（尤其是 WebForm）做一个课程设计、毕业设计，或者想通过一个完整项目来巩固 .NET 基础，那这篇实战记录应该能帮你省下不少摸索的时间。

1. 项目整体设计与思路拆解

1.1 从需求到表结构：点餐系统到底在管什么

很多人一上来就急着写代码，但真正开工前，我花了两天时间在纸上画业务流程。点餐系统听起来简单，无非就是“用户看菜单 -> 加购物车 -> 下单”，但它背后还牵扯到后台管理：菜品谁维护？订单状态谁来改？这些如果不提前想清楚，写代码的时候会不断返工。

我最终把系统拆成了三个核心模块：

• 用户前台：菜品分类展示、菜品列表、购物车管理、提交订单。
• 后台管理：菜品信息维护（增删改查）、订单状态管理（待处理/已完成）。
• 公共模块：用户会话保持（Session）、购物车数据持久化（ViewState + DataTable）、数据库访问封装。

对应的数据库，我设计了四张表：

在设计 Orders 表的时候，我犹豫过要不要再建一张订单明细表 OrderDetail，把每道菜的数量、单价单独存起来。后来考虑到项目规模和时间限制，我选择把购物车中的商品拼接成字符串存入 TotalPrice 对应的明细字段（实际上我加了一个 FoodList 字段存放明细），这样确实损失了一定的规范性，但对于三类菜品的点单场景，查询起来反而更直接，而且减少了联表查询的复杂度。这种取舍在实际开发里很常见——先跑通流程，再谈优化。

1.2 技术选型：为什么用 WebForm 而不是 MVC

现在网上铺天盖地都是 ASP.NET Core 和前后端分离，很多人可能会问，为什么还用 ASP.NET WebForm？其实答案很实在：WebForm 的事件驱动模型对于做管理系统类项目非常高效，尤其是 GridView、DataList 这些服务器控件，拖拽绑定就能完成大量表格展示功能，开发速度极快。

在这个项目里，我用到了这些关键技术点：

• ASP.NET WebForm 页面生命周期：理解 Page_Load、IsPostBack 的用法，这是 WebForm 开发的基石。
• C# 基础与 LINQ：用 LINQ 操作 DataTable，筛选菜品、计算总价。
• ADO.NET / SqlConnection：手写 SQL 语句完成数据库增删改查，没有用 EF，因为想搞清楚底层连接是怎么一回事。
• 三层架构：UI（页面）、BLL（业务逻辑）、DAL（数据访问）分离，代码写在 App_Code 下。
• 前端技术：HTML + CSS + JavaScript + jQuery + Ajax，以及 Bootstrap 美化界面。
• ViewState 与 Session：解决购物车数据“记住”的问题，这也是 WebForm 特有的状态管理方式。

这套组合在当时（甚至现在）做课程设计和毕业设计都是很稳的选择，既能体现后端功底，又不会因为框架过于复杂导致自己陷入“只会调用不懂原理”的尴尬。

2. 开发环境准备与数据库设计实操

2.1 开发工具与运行环境配置

工欲善其事，必先利其器。我用的开发环境是：

• Visual Studio 2019：社区版就够用，不需要付费。
• SQL Server 2019 Express：轻量级，适合学习和小型项目，注意要启用 sa 账号和 SQL Server 身份验证模式，否则连接字符串会报登录失败。
• .NET Framework 4.6.1：WebForm 在 .NET Framework 下的支持最稳定。

在创建项目的时候，记得选择“ASP.NET Web 应用程序 (.NET Framework)”，然后在模板里挑“Web Forms”。这里有一步非常容易被忽略：很多人建完项目就直接开写，结果发现找不到 App_Code 文件夹。解决办法是右键项目 -> 添加 -> 添加 ASP.NET 文件夹 -> App_Code，这个文件夹专门用来存放 .cs 类文件，它里面的代码会被自动编译成程序集，不需要手动引用。

提示：如果你用的是 VS2022 或更高版本，WebForm 项目模板仍然存在，只是在新建项目时需要在搜索框输入“Web Forms”筛选，别找半天找不到。

2.2 数据库脚本与连接字符串解析

数据库脚本我是直接在 SQL Server Management Studio 里执行的，核心建表语句如下：

sql复制CREATE TABLE [dbo].[UserInfo] (
    [UserId]   INT           IDENTITY (1, 1) NOT NULL,
    [UserName] NVARCHAR (50) NOT NULL,
    [Password] NVARCHAR (50) NOT NULL,
    PRIMARY KEY CLUSTERED ([UserId] ASC)
);

CREATE TABLE [dbo].[FoodClass] (
    [ClassId]   INT           IDENTITY (1, 1) NOT NULL,
    [ClassName] NVARCHAR (50) NOT NULL,
    [ClassDesc] NVARCHAR (200) NULL,
    PRIMARY KEY CLUSTERED ([ClassId] ASC)
);

CREATE TABLE [dbo].[Food] (
    [FoodId]      INT             IDENTITY (1, 1) NOT NULL,
    [FoodName]    NVARCHAR (50)   NOT NULL,
    [FoodPrice]   DECIMAL (18, 2) NOT NULL,
    [FoodClassId] INT             NOT NULL,
    [FoodDesc]    NVARCHAR (MAX)  NULL,
    PRIMARY KEY CLUSTERED ([FoodId] ASC),
    CONSTRAINT [FK_Food_ToFoodClass] FOREIGN KEY ([FoodClassId]) 
        REFERENCES [dbo].[FoodClass] ([ClassId]) ON DELETE CASCADE
);

CREATE TABLE [dbo].[Orders] (
    [OrderId]     INT             IDENTITY (1, 1) NOT NULL,
    [OrderDate]   DATETIME        NOT NULL,
    [UserName]    NVARCHAR (50)   NOT NULL,
    [IsProcessed] BIT             NOT NULL,
    [TotalPrice]  DECIMAL (18, 2) NOT NULL,
    [FoodList]    NVARCHAR (MAX)  NULL,
    PRIMARY KEY CLUSTERED ([OrderId] ASC)
);

关于 Food 表的外键，我设置了 ON DELETE CASCADE，这样删除菜品分类时，该分类下的菜品会自动级联删除。这点在后台管理里面非常实用，但也提醒一句：如果业务上有需要保留历史订单的场景，这种设计就会带来风险，所以实际项目中要根据需求权衡，这里是演示项目，我选择了操作便捷。

连接字符串放在 Web.config 里：

xml复制<connectionStrings>
    <add name="dbConnection" 
         connectionString="Data Source=.;Initial Catalog=OrderSystemDB;User ID=sa;Password=123456;"
         providerName="System.Data.SqlClient" />
</connectionStrings>

这里有个常见问题：Data Source=localhost 连不上，但改成 Data Source=. 或者 Data Source=.\SQLEXPRESS 就能通。原因在于 SQL Server Express 默认实例名是 SQLEXPRESS，如果你安装的是默认实例，直接用 . 就行；如果装了命名实例，必须写 .\SQLEXPRESS。这个细节我当初排查了整整一个下午。

3. 核心代码实现：三层架构与购物车逻辑

3.1 数据访问层（DAL）：通用的 SqlHelper 封装

我不想在每个页面都写一遍打开连接、执行命令、关闭连接的模板代码，所以先封装了一个通用的数据库操作类 SqlHelper，放在 App_Code 下。

csharp复制using System;
using System.Configuration;
using System.Data;
using System.Data.SqlClient;

public static class SqlHelper
{
    private static readonly string connStr = 
        ConfigurationManager.ConnectionStrings["dbConnection"].ConnectionString;

    /// <summary>
    /// 执行查询，返回 DataTable
    /// </summary>
    public static DataTable ExecuteDataTable(string sql, params SqlParameter[] parameters)
    {
        using (SqlConnection conn = new SqlConnection(connStr))
        {
            conn.Open();
            using (SqlCommand cmd = new SqlCommand(sql, conn))
            {
                if (parameters != null)
                    cmd.Parameters.AddRange(parameters);
                SqlDataAdapter adapter = new SqlDataAdapter(cmd);
                DataTable dt = new DataTable();
                adapter.Fill(dt);
                return dt;
            }
        }
    }

    /// <summary>
    /// 执行增删改，返回受影响行数
    /// </summary>
    public static int ExecuteNonQuery(string sql, params SqlParameter[] parameters)
    {
        using (SqlConnection conn = new SqlConnection(connStr))
        {
            conn.Open();
            using (SqlCommand cmd = new SqlCommand(sql, conn))
            {
                if (parameters != null)
                    cmd.Parameters.AddRange(parameters);
                return cmd.ExecuteNonQuery();
            }
        }
    }

    /// <summary>
    /// 执行聚合函数，返回首行首列值
    /// </summary>
    public static object ExecuteScalar(string sql, params SqlParameter[] parameters)
    {
        using (SqlConnection conn = new SqlConnection(connStr))
        {
            conn.Open();
            using (SqlCommand cmd = new SqlCommand(sql, conn))
            {
                if (parameters != null)
                    cmd.Parameters.AddRange(parameters);
                return cmd.ExecuteScalar();
            }
        }
    }
}

这里用到了 using 块，确保连接对象用完后自动释放。为什么推荐在 SqlHelper 内部每次新建连接而不是用静态共享连接？因为 SqlConnection 底层有连接池机制，每次 Open 实际上是从池里拿现成的连接，用完归还，频繁创建销毁并不损耗性能，反而避免了多个请求共用同一个连接引发的资源竞争问题。这一点在我后来做高并发测试时体会特别深——共享连接是最容易出死锁的写法。

3.2 业务逻辑层（BLL）：FoodManager 与 OrderManager

在 App_Code 下，我创建了两个业务逻辑类，用来隔离 UI 层和数据库访问逻辑。

csharp复制public class FoodManager
{
    /// <summary>
    /// 根据菜品分类ID获取菜品列表
    /// </summary>
    public DataTable GetFoodsByClassId(int classId)
    {
        string sql = "SELECT * FROM Food WHERE FoodClassId = @classId";
        SqlParameter param = new SqlParameter("@classId", classId);
        return SqlHelper.ExecuteDataTable(sql, param);
    }

    /// <summary>
    /// 获取所有菜品
    /// </summary>
    public DataTable GetAllFoods()
    {
        string sql = "SELECT * FROM Food";
        return SqlHelper.ExecuteDataTable(sql);
    }

    /// <summary>
    /// 添加菜品（后台管理使用）
    /// </summary>
    public bool AddFood(string name, decimal price, int classId, string desc)
    {
        string sql = "INSERT INTO Food(FoodName, FoodPrice, FoodClassId, FoodDesc) VALUES(@name, @price, @classId, @desc)";
        SqlParameter[] paras = {
            new SqlParameter("@name", name),
            new SqlParameter("@price", price),
            new SqlParameter("@classId", classId),
            new SqlParameter("@desc", desc ?? DBNull.Value.ToString())
        };
        return SqlHelper.ExecuteNonQuery(sql, paras) > 0;
    }
}

public class OrderManager
{
    /// <summary>
    /// 创建订单
    /// </summary>
    public bool CreateOrder(string userName, decimal totalPrice, DataTable cartTable)
    {
        string foodList = "";
        foreach (DataRow row in cartTable.Rows)
        {
            foodList += row["FoodName"] + " x " + row["Count"] + "；";
        }

        string sql = "INSERT INTO Orders(OrderDate, UserName, IsProcessed, TotalPrice, FoodList) VALUES(@date, @user, 0, @price, @foodList)";
        SqlParameter[] paras = {
            new SqlParameter("@date", DateTime.Now),
            new SqlParameter("@user", userName),
            new SqlParameter("@price", totalPrice),
            new SqlParameter("@foodList", foodList)
        };
        return SqlHelper.ExecuteNonQuery(sql, paras) > 0;
    }
}

这段代码里有一个细节值得多说一句：AddFood 中描述字段我用 DBNull.Value.ToString() 来处理空值，这种做法其实不太优雅，更规范的方式应该是判断如果是 null 就传入 DBNull.Value。但在实际开发中，只要前端表单做了校验，这个逻辑基本不会出问题。我在代码评审时被同事指出过这个问题，后来改成这样：

csharp复制new SqlParameter("@desc", string.IsNullOrEmpty(desc) ? DBNull.Value : (object)desc)

3.3 购物车的核心存储结构：DataTable 当临时内存表

购物车是点餐系统最核心的交互模块。我在 WebForm 里用 ViewState 存储了一个 DataTable 对象，用来模拟购物车中的商品行。为什么选 DataTable 而不是 List<CartItem>？因为 DataTable 自带 Select 方法，筛选某一行是否存在时非常方便，直接 table.Select("FoodId = " + id) 就能拿到行，不需要写循环遍历。

购物车的核心操作包括：添加菜品、修改数量、计算总价。我封装在 CartManager.cs 中：

csharp复制public class CartManager
{
    /// <summary>
    /// 创建一个购物车 DataTable
    /// </summary>
    public static DataTable CreateCartTable()
    {
        DataTable dt = new DataTable();
        dt.Columns.Add("FoodId", typeof(int));
        dt.Columns.Add("FoodName", typeof(string));
        dt.Columns.Add("Price", typeof(decimal));
        dt.Columns.Add("Count", typeof(int));
        dt.Columns.Add("TotalPrice", typeof(decimal), "Price * Count");
        return dt;
    }

    /// <summary>
    /// 将 DataTable 存入 ViewState
    /// </summary>
    public static void SaveCart(DataTable cart, StateBag viewState)
    {
        viewState["Cart"] = cart;
    }

    /// <summary>
    /// 从 ViewState 获取购物车
    /// </summary>
    public static DataTable GetCart(StateBag viewState)
    {
        if (viewState["Cart"] == null)
        {
            viewState["Cart"] = CreateCartTable();
        }
        return viewState["Cart"] as DataTable;
    }
}

这里使用 StateBag 作为参数类型，是为了让这个类不直接依赖具体的 Page 对象，方便单元测试。ViewState 的本质是 StateBag 类，页面所有服务器控件的状态都保存在这里面。在购物车场景中，每次触发事件（比如点击“加入购物车”）都会导致页面回发（PostBack），页面重建后从 ViewState 里恢复购物车数据，这正是 WebForm 事件驱动模型的核心应用。

3.4 UI 层：通过事件驱动串联整个页面流程

以点餐主页 Order.aspx 为例，页面布局用了 Bootstrap 的栅格系统，左边是分类列表，右边是菜品展示。分类点击之后，通过 LinkButton 的 CommandArgument 传递分类ID，触发 SelectedClass 事件：

aspx复制<asp:Repeater ID="rptClass" runat="server" OnItemCommand="rptClass_ItemCommand">
    <ItemTemplate>
        <li>
            <asp:LinkButton runat="server" 
                Text='<%# Eval("ClassName") %>' 
                CommandArgument='<%# Eval("ClassId") %>' 
                CommandName="SelectClass" />
        </li>
    </ItemTemplate>
</asp:Repeater>

后端事件处理：

csharp复制protected void rptClass_ItemCommand(object source, RepeaterCommandEventArgs e)
{
    if (e.CommandName == "SelectClass")
    {
        int classId = Convert.ToInt32(e.CommandArgument);
        FoodManager manager = new FoodManager();
        DataTable foods = manager.GetFoodsByClassId(classId);
        rptFoods.DataSource = foods;
        rptFoods.DataBind();
    }
}

这个流程里最有价值的一点是，它展示了一个 WebForm 页面如何处理“列表展示 + 二级联动”的常见需求。很多初学者会困惑：为什么点击分类之后整个页面刷新了？因为 LinkButton 默认会触发 __doPostBack，将页面提交到服务器，然后服务器重新执行整个页面生命周期。在这个过程中，Page_Load 会再次执行，所以务必在 Page_Load 里用 if (!IsPostBack) 包裹初次加载的逻辑，否则每次点击分类，菜品列表都会被重置。

csharp复制protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        // 初始化分类列表和默认菜品列表
        FoodManager manager = new FoodManager();
        rptClass.DataSource = manager.GetAllClasses();
        rptClass.DataBind();
        rptFoods.DataSource = manager.GetAllFoods();
        rptFoods.DataBind();
    }
}

4. 购物车与订单提交：ViewState、Session 与 Ajax 的结合

4.1 加入购物车：从“数据行保存”到“页面反馈”

购物车这个功能，在互联网点餐场景下是绝对不能刷新页面的。用户在点菜的时候，每点一道菜就刷新一次页面，体验可以说是灾难级的。所以这里我用 jQuery + Ajax 调用了后端的 一般处理程序（HttpHandler），也就是 .ashx 文件，实现无刷新地加入购物车。

CartHandler.ashx 的处理逻辑如下：

csharp复制public class CartHandler : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text/plain";
        string action = context.Request["action"]; // add / update / remove

        // 购物车数据从 Session 中读取，而不是 ViewState
        DataTable cart = context.Session["Cart"] as DataTable;
        if (cart == null)
        {
            cart = CartManager.CreateCartTable();
            context.Session["Cart"] = cart;
        }

        if (action == "add")
        {
            int foodId = Convert.ToInt32(context.Request["foodId"]);
            string foodName = context.Request["foodName"];
            decimal price = Convert.ToDecimal(context.Request["price"]);

            DataRow[] rows = cart.Select("FoodId = " + foodId);
            if (rows.Length > 0)
            {
                rows[0]["Count"] = (int)rows[0]["Count"] + 1;
            }
            else
            {
                DataRow newRow = cart.NewRow();
                newRow["FoodId"] = foodId;
                newRow["FoodName"] = foodName;
                newRow["Price"] = price;
                newRow["Count"] = 1;
                cart.Rows.Add(newRow);
            }
            context.Session["Cart"] = cart;

            // 返回最新购物车总数
            int totalCount = 0;
            foreach (DataRow row in cart.Rows)
                totalCount += (int)row["Count"];
            context.Response.Write(totalCount);
        }
        context.Response.End();
    }

    public bool IsReusable { get { return false; } }
}

这里有一个非常关键的设计决策：为什么购物车用 Session 而不是 ViewState？因为 Ajax 请求是不经过页面生命周期重建的——它是直接从浏览器发到服务器的一个独立 HTTP 请求，服务器在处理这个请求时并没有当前的页面实例，所以 ViewState 完全不可用。而 Session 是以会话为粒度存储在服务器端的，任何一个请求只要带了正确的 Cookie（ASP.NET_SessionId），都能读写同一个 Session 字典。这就是“购物车数据跨请求共享”的正确打开方式。

前端调用方式：

javascript复制function addToCart(foodId, foodName, price) {
    $.ajax({
        url: "CartHandler.ashx",
        type: "POST",
        data: {
            action: "add",
            foodId: foodId,
            foodName: foodName,
            price: price
        },
        success: function (result) {
            // 更新导航栏购物车角标数量
            $("#cartBadge").text(result);
            alert("已加入购物车！");
        },
        error: function () {
            alert("操作失败，请稍后重试");
        }
    });
}

4.2 购物车页面：Repeater 展示与总价计算

单独的购物车页面 Cart.aspx 用于展示当前用户选中的全部菜品，并允许修改数量或删除。这个页面的数据源直接来自 Session["Cart"]，填充到 Repeater 控件中展示。

在修改数量时，我依然是使用 Ajax 调用 CartHandler.ashx 中的 update 动作。当数量减少到 0 时自动移除该行：

csharp复制if (action == "update")
{
    int foodId = Convert.ToInt32(context.Request["foodId"]);
    int newCount = Convert.ToInt32(context.Request["newCount"]);

    DataRow[] rows = cart.Select("FoodId = " + foodId);
    if (rows.Length > 0)
    {
        if (newCount <= 0)
            cart.Rows.Remove(rows[0]);
        else
            rows[0]["Count"] = newCount;
    }
    context.Session["Cart"] = cart;

    // 返回新的总价和总数量，一次请求批量更新前端页面数据
    decimal totalPrice = 0;
    int totalCount = 0;
    foreach (DataRow row in cart.Rows)
    {
        totalPrice += (decimal)row["TotalPrice"];
        totalCount += (int)row["Count"];
    }
    context.Response.Write(totalPrice + "|" + totalCount);
}

这里我返回了 "总价|总数量" 这样一个用竖线分隔的字符串，前端拿到之后再拆分开更新两个 DOM 元素。这种设计简单直接，但要注意：如果数据里本身就包含竖线字符，就会解析错位。更稳妥的做法是用 JSON 序列化，这里为了减少引库依赖，我采用了最原始的分隔符方案。

4.3 提交订单：事务处理防止数据不一致

提交订单是整个流程中唯一涉及“写入”的操作，为了防止用户连续点击“提交订单”按钮导致重复下单，我做了两层防护：

1. 前端置灰按钮：点击提交后，按钮立即设置为 disabled，防止重复提交。
2. 后端判断 Session 购物车是否为空：为空直接返回。

订单提交的代码放在 OrderHandler.ashx：

csharp复制if (action == "submit")
{
    if (context.Session["Cart"] == null)
    {
        context.Response.Write("empty");
        return;
    }

    DataTable cart = context.Session["Cart"] as DataTable;
    if (cart.Rows.Count == 0)
    {
        context.Response.Write("empty");
        return;
    }

    string userName = context.Session["UserName"].ToString();
    decimal totalPrice = 0;
    foreach (DataRow row in cart.Rows)
        totalPrice += (decimal)row["TotalPrice"];

    OrderManager manager = new OrderManager();
    bool success = manager.CreateOrder(userName, totalPrice, cart);

    if (success)
    {
        context.Session["Cart"] = null; // 清空购物车
        context.Response.Write("success");
    }
    else
    {
        context.Response.Write("error");
    }
}

这里有个我自己后来才意识到的潜在问题：CreateOrder 方法内部其实是先拼装 foodList 字符串再执行插入的，它和“读取购物车计算总价”是两个独立的操作，如果在高并发场景下，用户同时提交两次订单，确实可能产生重复数据。要彻底解决需要引入数据库事务或者应用层分布式锁，但在这个级别的项目里，前端按钮防抖加后端 Session 判空已经足够了。作为学习者，你应该知道这层局限在哪，而不是假装它不存在。

5. 后台管理模块与文件上传实战

5.1 管理员登录与权限校验

后台管理页面不能允许普通用户随便访问。我的解决方案非常轻量：登录时在 Session 中存一个管理员标识，后台每个页面在 Page_Load 中统一校验。

csharp复制protected void Page_Load(object sender, EventArgs e)
{
    if (Session["IsAdmin"] == null || !(bool)Session["IsAdmin"])
    {
        Response.Redirect("Login.aspx?returnUrl=Admin/Default.aspx");
    }
}

后来我嫌每个页面写一遍太麻烦，就抽了一个 BaseAdminPage 基类，让所有后台页面继承它：

csharp复制public class BaseAdminPage : System.Web.UI.Page
{
    protected override void OnLoad(EventArgs e)
    {
        if (Session["IsAdmin"] == null || !(bool)Session["IsAdmin"])
        {
            Response.Redirect("~/Login.aspx?returnUrl=" + Server.UrlEncode(Request.Url.PathAndQuery));
        }
        base.OnLoad(e);
    }
}

这样后台页面只需要把 public partial class Default : BaseAdminPage 这样声明，权限校验就自动生效了。这算是一个很典型的“重构收益”案例——花了十几分钟做基类，省掉了后面每个页面重复写 5 行代码的功夫。

5.2 菜品图片上传与显示

菜品图片上传用了 FileUpload 控件和后端保存逻辑。这里有几个坑需要特别强调：

1. 服务器端必须校验文件类型：不能相信前端 accept="image/*" 的限制，因为请求可以被伪造。我在后端用文件扩展名白名单做校验。
2. 文件名必须重命名：如果直接用户上传的文件名存储，会存在路径穿越和文件名冲突的风险。我用 Guid 重命名文件，保留了原扩展名。
3. 保存路径和显示路径要分开：物理路径用 Server.MapPath("~/Uploads/")，用于文件系统存储；显示时用相对路径 "/Uploads/" + fileName，用于拼接 img 标签。

csharp复制protected void btnUpload_Click(object sender, EventArgs e)
{
    if (!FileUpload1.HasFile)
    {
        lblMsg.Text = "请先选择文件";
        return;
    }

    string fileName = FileUpload1.FileName;
    string ext = Path.GetExtension(fileName).ToLower();

    if (ext != ".jpg" && ext != ".jpeg" && ext != ".png" && ext != ".gif")
    {
        lblMsg.Text = "仅支持 jpg/jpeg/png/gif 格式图片";
        return;
    }

    string newName = Guid.NewGuid().ToString("N") + ext;
    string savePath = Server.MapPath("~/Uploads/") + newName;
    FileUpload1.SaveAs(savePath);

    // 将相对路径存入数据库对应字段
    string relativePath = "/Uploads/" + newName;
    // 调用 FoodManager.UpdateFoodImage(foodId, relativePath) 更新数据库
}

5.3 订单处理列表：给管理员一个清晰的视图

后台订单列表用 GridView 展示，绑定了 Orders 表的数据。这里我用了模板列加上一个“标记已完成”的按钮，按钮的 CommandArgument 是订单 ID，点击时更新 IsProcessed 字段。

aspx复制<asp:GridView ID="gvOrders" runat="server" AutoGenerateColumns="False" 
              OnRowCommand="gvOrders_RowCommand" DataKeyNames="OrderId">
    <Columns>
        <asp:BoundField DataField="OrderId" HeaderText="订单号" />
        <asp:BoundField DataField="UserName" HeaderText="用户名" />
        <asp:BoundField DataField="OrderDate" HeaderText="下单时间" />
        <asp:BoundField DataField="TotalPrice" HeaderText="总金额" />
        <asp:BoundField DataField="FoodList" HeaderText="菜品明细" />
        <asp:BoundField DataField="IsProcessed" HeaderText="状态" />
        <asp:TemplateField HeaderText="操作">
            <ItemTemplate>
                <asp:Button ID="btnProcess" runat="server" Text="标记完成" 
                    CommandName="Process" CommandArgument='<%# Eval("OrderId") %>' />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

这里我刻意用了 BoundField 直接绑定 IsProcessed 的布尔值，结果页面上显示的是 True/False，不够友好。后来我改成模板列，里面放一个 Label，根据 IsProcessed 的值动态设置 Text 和 CssClass：

csharp复制protected void gvOrders_RowDataBound(object sender, GridViewRowEventArgs e)
{
    if (e.Row.RowType == DataControlRowType.DataRow)
    {
        DataRowView rowView = e.Row.DataItem as DataRowView;
        bool isProcessed = (bool)rowView["IsProcessed"];
        Label lblStatus = e.Row.FindControl("lblStatus") as Label;
        if (lblStatus != null)
        {
            lblStatus.Text = isProcessed ? "已完成" : "待处理";
            lblStatus.CssClass = isProcessed ? "badge bg-success" : "badge bg-warning";
        }
    }
}

6. 引入 ASP.NET MVC 架构：从 WebForm 到前后端分离的思考

6.1 项目中期重构的动机

写到这里，我想聊聊我接触 ASP.NET 后期最深刻的感受。我的点餐系统中期版本一直是 WebForm 架构，直到有次我去面试，面试官问了我一个问题：“如果你的点餐系统要同时支持微信小程序、App 和 Web 三个端，你会怎么设计服务端？”

那一刻我意识到，WebForm 的服务器控件渲染 HTML 的方式，本质上把“前端展示”和“后端逻辑”揉得太紧了。小程序和 App 根本不关心你服务器的 aspx 页面生成了什么 HTML，它们只要数据——JSON 格式的数据。这就引出了 ASP.NET MVC + Web API 的前后端分离方案。

6.2 MVC 模式如何解决点餐系统的扩展问题

在 MVC 架构下，点餐系统的设计变成了这样：

• Model（模型）：Food、Order、User 实体类，对应数据库表。
• View（视图）：Index.cshtml 里用 $.ajax 请求 API 接口，拿到 JSON 数据后用 JS 动态渲染。
• Controller（控制器）：FoodController、OrderController，只负责接收请求、调用业务逻辑、返回 JSON。

比如获取菜品列表的接口，代码可以精简成这样：

csharp复制public class FoodController : ApiController
{
    public IHttpActionResult GetFoodsByClass(int classId)
    {
        FoodManager manager = new FoodManager();
        DataTable dt = manager.GetFoodsByClassId(classId);
        // 将 DataTable 转为 JSON 返回
        return Json(ConvertDataTableToList(dt));
    }
}

前端就变成了纯粹的数据展示层，想适配小程序，直接在小程序里用 wx.request 请求同样的接口就行；想适配 App，用 HttpClient（C# 桌面端）或者 Retrofit（Android）请求同样的接口就行。服务端根本不用动，改的只是“谁来消费这些 JSON”。

这也是我在做项目过程中最想强调的一点：如果你已经用三层架构把 FoodManager、OrderManager 这样的业务逻辑从 UI 层剥离出来了，那么从 WebForm 迁移到 MVC 的成本其实很低——你只需要把原来 aspx 页面里的后台代码删掉，换成控制器输出 JSON 即可。做项目的时候，一定要把业务逻辑写在独立的类里，而不是堆在页面后台代码中，这个习惯会在未来救你无数次。

7. 项目部署与常见问题排查

7.1 本地 IIS 部署流程

开发完后，我把项目发布并部署到了本机 IIS。这一步本身不难，但坑不少，整理一下正常流程：

1. 发布网站：VS 里右键项目 -> 发布 -> 选择“文件夹”发布，生成发布包。
2. IIS 添加网站：物理路径指向发布文件夹，绑定端口（比如 8080）。
3. 应用程序池设置：这是最容易出错的一步。如果你的系统是 64 位，但引用了 32 位组件，需要把应用程序池的“启用 32 位应用程序”设为 True。此外，.NET 版本要选 v4.0，集成托管管道模式选“集成”。
4. 权限问题：数据库连接如果用的是 sa 账号，一般没问题；但如果用 Windows 身份验证，需要给 IIS 应用程序池的身份（如 IIS AppPool\YourPoolName）赋予数据库的登录权限。

7.2 常见问题速查表

其中 IRequiresSessionState 这个坑特别隐蔽。默认情况下，IHttpHandler 实现的处理程序是不启用 Session 的，如果你在 ProcessRequest 里直接读写 context.Session，它会抛 NullReferenceException 或者直接拿到空值。解决办法是实现 IRequiresSessionState 标记接口：

csharp复制public class CartHandler : IHttpHandler, IRequiresSessionState
{
    // ...
}

这个接口里没有任何方法，它只是一个“标记”，告诉 ASP.NET 运行时：“这个处理程序需要用到 Session 状态。”没有它，Session 就是空中楼阁。

7.3 日志记录：没有日志的线上系统等于盲人摸象

项目跑起来之后，为了防止出现报错时一脸茫然，我加了一个最简单的日志机制——把异常信息写进文本文件。

csharp复制public static class LogHelper
{
    public static void WriteLog(string msg)
    {
        string path = HttpContext.Current.Server.MapPath("~/Logs/");
        if (!Directory.Exists(path))
            Directory.CreateDirectory(path);

        string file = Path.Combine(path, DateTime.Now.ToString("yyyyMMdd") + ".txt");
        File.AppendAllText(file, $"[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] {msg}\r\n");
    }
}

然后在 Global.asax 的 Application_Error 事件里统一捕获未处理异常：

csharp复制protected void Application_Error(object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();
    LogHelper.WriteLog("全局异常：" + ex.ToString());
}

虽然简单，但在调试阶段救了我好几次——有一次 Ajax 一直报 500，浏览器控制台只显示“Internal Server Error”，完全看不到后端具体异常，全靠这个日志文件定位到了是数据库连接字符串里密码带特殊字符导致的问题。没有任何日志系统的项目，出问题时你连从哪里开始排查都不知道。

8. 踩坑记录与项目复盘

8.1 生命周期认知不清导致的“数据消失”

我踩过最典型的坑，是把购物车存到了 ViewState 里，然后通过 Ajax 去修改它。结果每次 Ajax 请求之后，页面上显示的购物车数量还是原来的。

原因我在前面已经说过：Ajax 请求（通过 $.ajax 到的 .ashx）不经过 aspx 页面的生命周期，自然不会生成和读取页面的 ViewState。购物车数据放在 ViewState 里，只有页面自身的回发（__doPostBack）才能访问到。所以当后台返回最新数量时，前端拿到的永远是旧值或空值。

这个问题的根本解法就是购物车这种跨请求状态必须放在 Session 而不是 ViewState。这也是我在后面设计 CartHandler 时坚持用 Session 的原因。

8.2 防重复提交：不只是按钮禁用那么简单

按钮禁用能挡住普通用户，但挡不住技术人员直接从浏览器控制台发起第二次 Ajax 请求。所以后端必须要对“订单是否已提交”做幂等校验。

在点餐系统中，我在 Session 里用一个标志位（OrderSubmitted）来防止重复提交：

csharp复制if (context.Session["OrderSubmitted"] != null && (bool)context.Session["OrderSubmitted"])
{
    context.Response.Write("submitted");
    return;
}

// 执行下单逻辑
context.Session["OrderSubmitted"] = true;

这个标志位在购物车被清空时同时重置。但从严格意义上讲，这只防了“同一会话内”的重复提交，如果要防“同一用户在不同设备上的重复提交”，就需要在数据库层面做唯一性约束了。每一种方案都有适用边界的，你要知道自己在防什么，以及这个方案的边界在哪。

8.3 命名空间与类文件的组织

写 App_Code 下的类时，最开始我把所有类都放在默认的全局命名空间里，结果页面后台代码调用时经常冲突——比如有两个不同的类都叫 CartManager（一个在 App_Code，一个在页面代码里）。后来我按照功能拆分命名空间：

csharp复制namespace MyOrderSystem.Model { ... } // 实体类
namespace MyOrderSystem.DAL { ... }   // 数据访问
namespace MyOrderSystem.BLL { ... }   // 业务逻辑
namespace MyOrderSystem.UIHelper { ... } // 购物车辅助等

页面后台代码里再用 using 引入。这个习惯让我在项目后期维护时省了不少时间——看到命名空间就知道这段代码属于哪一层，不用满世界找类定义。

9. 从点餐系统到更广阔的世界

这个点餐系统做完之后，我一度觉得它太简单了，甚至有点拿不出手。但后来我慢慢发现，项目的价值不在于它用了多牛的技术，而在于它帮你验证了多少“原来如此”的瞬间。

从这个小项目里，我确确实实掌握了：

• ASP.NET 页面生命周期和事件驱动模型，理解了 IsPostBack 为什么是 WebForm 开发的第一行代码。
• 三层架构的边界划分：UI 层只做展示和交互，BLL 层只做业务规则，DAL 层只做 SQL 操作。
• Session、ViewState、Cookie 各自的作用范围和适用场景。
• Ajax 和后端接口的配合方式，以及无刷新交互的实现路径。
• 从 WebForm 到 MVC 的演进逻辑，明白了前后端分离到底在“分”什么。

如果你也想用一个项目练手 ASP.NET，我建议你从点餐系统、宿舍管理系统、图书馆管理系统这类“增删改查 + 状态管理”的项目入手。它们看起来不起眼，但背后涉及的 Web 开发核心知识非常全面。那些直接上手微服务、消息队列、容器化部署的初学者，往往连最基本的“Session 和 ViewState 有什么区别”都说不清楚。

最后再分享一个小技巧：做完项目之后，花一个晚上把所有页面关闭，然后打开 VS 的“生成”输出窗口，把所有警告（Warning）挨个看一遍。别嫌烦，那些绿色的警告里藏着大量你平时忽略的细节——比如未使用的变量、可能为空的引用、过时的 API。把每个警告都弄清楚，你的代码质量会上一个台阶。我在清理完这个点餐系统的全部警告之后，再看之前写的代码，确实有种“当初怎么写出这种垃圾”的感觉。这种“嫌弃过去的自己”的瞬间，就是实打实的成长。