简介这是一份基于C#的C/S架构库存管理系统完整工程面向学习C#桌面应用、数据库课程设计或仓储管理开发的初学者。系统涵盖商品入库、出库、库存盘点、预警等核心功能模块有助于理解从数据库设计到客户端交互的完整链路。压缩包共309个文件约4.74MB核心为62个C#源码文件另含数据库表注释文档、可直接运行的exe程序、25组resx/resources界面资源配置并配有大量图标、背景图片及数据库备份结构清晰便于按模块查阅。目前已有350人学习、浏览是参考书实例的实践版本。通过该工程读者可直观对照界面与后台代码学习C/S模式下的数据访问、业务逻辑封装和界面事件处理配套的数据库表注释文档则有助于快速弄清各表字段含义借鉴其字段设计与系统分层思路为独立开发小型管理系统提供一手范例。1. 一套C#的C/S库存管理系统从登录到盘点的完整闭环如果仓库管理员每天下班前还要对着Excel把出货数减一遍、入库数加一遍那这套用C#做的C/S库存管理系统就是来替换手工台账的。它不是网页后台也不是手机App而是跑在Windows桌面的经典客户端程序WinForms画界面SQL Server存数据登录、商品分类、入库、出库、盘点、低库存预警这类日常操作全部落在C/S两端。适合课程设计选型、想体验传统桌面项目开发流程的人以及需要一套内网工具的中小规模场景。我拆完这套源码最深的感受是它把C#桌面开发里最容易忽略的三件事——分层解耦、事务安全、参数化查询——全用业务场景串起来了。跑通它一遍基本等于把C/S项目的骨架从头摸到了尾。2. 架构与数据库设计BLL/DAL分层和五张核心表2.1 技术选型为什么是WinForms而不是Web这套系统选型C# WinForms SQL Server走的完全是C/S架构的老路。C/S在这里不是缺点恰恰是它适合内网库存业务的理由客户端直连数据库局域网内响应快不上外网也能用服务器压力小部署形态就是一台装了SQL Server的机器加若干台装了客户端的PC。对比一下C/S和B/S在实际使用中的差异对比点C/S本项目B/S部署每台客户端装exe升级要替换程序浏览器访问升级只改服务器网络局域网内直连数据库需要Web服务器IIS等离线能力数据库断开时本地可用需额外设计完全依赖网络性能客户端运算服务器压力小请求走HTTP链路更长开发成本WinForms控件生态成熟前端框架选型、接口维护更重如果这套项目当初做成Web光是登录态的Session管理、权限菜单的渲染、导出Excel的浏览器兼容就要多花不少时间。用WinForms把这些业务放在本地客户端很多问题被“所见即所得”地消化掉了。需要提醒的是这套源码没有做断网缓存数据库连不上客户端就直接罢工这也是C/S最常被吐槽的点后面第5章会展开讲。2.2 解决方案结构Models/DAL/BLL/UI四层怎么分工整套代码按经典的四层结构组织每个层一个类库项目Inventory.sln ├── Models // 实体类UserModel、ProductModel、InStockModel、OutStockModel │ ├── UserModel.cs │ ├── ProductModel.cs │ └── CategoryModel.cs ├── DAL // 数据访问层只负责SQL执行不写业务判断 │ ├── DbHelper.cs │ ├── UserDal.cs │ ├── ProductDal.cs │ └── StockDal.cs ├── BLL // 业务逻辑层事务控制、库存校验、登录验证 │ ├── UserService.cs │ ├── ProductService.cs │ └── StockService.cs ├── UI // WinForms界面MainForm、InStockForm、OutStockForm等 │ ├── LoginForm.cs │ ├── MainForm.cs │ ├── ProductManageForm.cs │ ├── InStockForm.cs │ └── OutStockForm.cs └── Common // 公共工具MD5加密、全局登录用户缓存 ├── Md5Helper.cs └── GlobalCache.csUI层只做两件事收集用户输入、把结果展示到控件。登录验证的规则、库存能不能扣、单据要不要回滚这些判断全部下沉到BLL。DAL层写最纯粹的ADO.NET操作连判断本都不带。我一般接手项目会先看这个层与层之间的引用关系Models被所有层引用DAL引用ModelsBLL引用DAL和ModelsUI只引用BLL和Models。如果发现UI直接new了SqlConnection说明分层已经被破坏后续改起来会很痛。这套源码的分层还算规矩哪怕只是改个SQL也能在不动界面的前提下完成。2.3 数据库建模五张表如何撑起进销存闭环数据库名叫InventoryDB核心业务表五张用户表、分类表、商品表、入库表、出库表。建表脚本如下节选最关键的商品表和入库表CREATE TABLE Product ( ProductID INT IDENTITY(1,1) PRIMARY KEY, ProductName NVARCHAR(100) NOT NULL, CategoryID INT NOT NULL, Spec NVARCHAR(50), -- 规格型号 Unit NVARCHAR(10), -- 单位件/箱/公斤 Price DECIMAL(10,2) DEFAULT 0, SafeStock INT DEFAULT 0, -- 安全库存量 Stock INT DEFAULT 0, -- 当前库存量 Remark NVARCHAR(200) ); CREATE TABLE InStock ( InStockID INT IDENTITY(1,1) PRIMARY KEY, ProductID INT NOT NULL, Quantity INT NOT NULL, -- 入库数量 UnitPrice DECIMAL(10,2), -- 入库单价 Supplier NVARCHAR(100), OperatorID INT NOT NULL, -- 操作人 InDate DATETIME DEFAULT GETDATE() );商品表的Stock字段是这套系统的核心。它不是算出来的而是每次入库、出库时直接在UPDATE语句里累加或递减比如Stock Stock qty。这种做法简单直接但如果并发没处理好就会出现库存错乱第5章的避坑环节会专门说这个问题。五张表的关联关系也很直白分类表是一级维度商品表挂在分类下商品被入库表和出库表引用。做盘点时就是把商品表的Stock和实际盘点的数量做差额对比生成盘盈盘亏记录。数据库没建视图统计报表时全部靠查询语句现场聚合比如查某天入库总量就是按CONVERT后的日期对InStock表分组求和。整体设计没有过度设计够用且好理解。3. 核心实现拆解登录鉴权、入库事务和库存预警3.1 登录鉴权MD5加盐和当前用户会话登录模块没有用复杂的身份框架就是传统的“查表比对”。不过密码没有明文入库而是先做了MD5加盐再存储这一点在同类课程设计里属于加分项。// Common/Md5Helper.cs 中的核心方法 public static string ComputeMD5(string rawText) { using (var md5 MD5.Create()) { byte[] bytes Encoding.UTF8.GetBytes(rawText); byte[] hash md5.ComputeHash(bytes); StringBuilder sb new StringBuilder(); for (int i 0; i hash.Length; i) { sb.Append(hash[i].ToString(x2)); // 转16进制小写 } return sb.ToString(); } }登录校验走BLL层的UserService注意密码加密时把用户名拼了进去public CurrentUser Login(string userName, string password) { // 加盐用户名参与哈希避免相同密码产生相同哈希值 string salted ${userName}:{password}; string md5Pwd Md5Helper.ComputeMD5(salted); string sql SELECT UserID, UserName, Role FROM Users WHERE UserName name AND Password pwd; DataTable dt SqlHelper.ExecuteQuery(sql, new SqlParameter(name, userName), new SqlParameter(pwd, md5Pwd)); if (dt.Rows.Count 0) return null; DataRow row dt.Rows[0]; return new CurrentUser { UserId Convert.ToInt32(row[UserID]), UserName row[UserName].ToString(), Role row[Role].ToString() // Admin 或 Operator }; }这段代码里有两个细节值得学一是密码哈希拼了用户名这个“盐”虽然简单但足以防止两个不同用户密码相同导致哈希值相同二是查询用了参数化SqlParameter避免SQL注入。整个登录流程里UI层拿到CurrentUser对象后把它存到GlobalCache里后面入库单、出库单的OperatorID都从这个全局缓存取这样每条单据都能追溯到操作人。3.2 入库操作事务把库存和流水绑在一起入库是这个项目里最有含金量的模块因为一次入库要干两件事往InStock表插一条流水同时把Product表的Stock字段加上数量。两件事必须同生共死否则就会出现流水记了但库存没加的脏数据。实现上用了SqlTransactionpublic bool DoInStock(InStockOrder order) { string sqlIn INSERT INTO InStock(ProductID, Quantity, UnitPrice, Supplier, OperatorID) VALUES(pid, qty, price, sup, opId); string sqlUpdate UPDATE Product SET Stock Stock qty WHERE ProductID pid; using (SqlConnection conn new SqlConnection(_connStr)) { conn.Open(); SqlTransaction tran conn.BeginTransaction(); try { SqlHelper.ExecuteNonQuery(tran, sqlIn, new SqlParameter(pid, order.ProductId), new SqlParameter(qty, order.Quantity), new SqlParameter(price, order.UnitPrice), new SqlParameter(sup, order.Supplier), new SqlParameter(opId, order.OperatorId)); SqlHelper.ExecuteNonQuery(tran, sqlUpdate, new SqlParameter(qty, order.Quantity), new SqlParameter(pid, order.ProductId)); tran.Commit(); return true; } catch (Exception ex) { tran.Rollback(); throw new Exception(入库失败已回滚该操作, ex); } } }这里的核心不是INSERT和UPDATE本身而是三点事务参数tran被传进了每个ExecuteNonQuery保证两条SQL在同一个事务里库存更新用的是Stock Stock qty而不是先SELECT再UPDATE这样避免读到旧值再覆盖写异常路径显式Rollback后把异常抛给UI层让界面弹窗提示。参数说明order.ProductId是入库商品IDorder.Quantity是本次入库数量order.Supplier是供应商名称order.OperatorId来自登录用户的UserId。出库模块和入库几乎对称只是UPDATE变成Stock Stock - qty并且多了扣减前校验库存是否足够的判断。3.3 低库存预警安全库存门槛和DataGridView标红预警模块做的比较务实每个商品可以设置SafeStock安全库存当Stock小于等于SafeStock就进入预警列表。商品管理界面维护安全库存值库存查询界面加载预警数据并按缺货程度排序。private void LoadWarningList() { string sql SELECT p.ProductID, p.ProductName, p.Unit, p.Stock, p.SafeStock FROM Product p WHERE p.Stock p.SafeStock ORDER BY (p.Stock - p.SafeStock) ASC; DataTable dt SqlHelper.ExecuteQuery(sql); dgvWarning.DataSource dt; // 高亮低于安全库存50%的标粉红其余标浅黄 foreach (DataGridViewRow row in dgvWarning.Rows) { int stock Convert.ToInt32(row.Cells[Stock].Value); int safe Convert.ToInt32(row.Cells[SafeStock].Value); if (stock safe * 0.5) { row.DefaultCellStyle.BackColor Color.LightPink; } else { row.DefaultCellStyle.BackColor Color.LightYellow; } } }这段代码的价值在于展示了一个常用套路DataGridView直接把DataTable作为数据源然后通过遍历行做视觉强调。注意排序用了(p.Stock - p.SafeStock) ASC缺货最严重的排最上面比单纯按库存排序更贴合业务——缺10件和缺100件显然不一样。预警没有做定时推送所有客户端打开预警窗体时刷新一次操作完出入库后手动刷新。如果要改成登录后自动弹窗在MainForm的Load事件里检查预警表是否有数据就行这个我在第6章的改造里会提到。4. 从源码到运行VS环境、建库脚本和打包部署4.1 环境准备Visual Studio与SQL Server的版本搭配这套源码面向.NET Framework 4.6.1开发所以Visual Studio用2017及以上版本都能直接打开。如果用的VS2022只需要在项目属性里确认Target Framework选的是.NET Framework 4.6.1或者直接升级到4.7.2/4.8也可以代码层面没有依赖老API。数据库方面SQL Server 2008 R2到2019都兼容Express版本足够。强烈建议安装时勾选“SQL Server身份验证模式”因为源码默认的连接字符串用的是账号密码登录如果只开Windows身份验证后面还要调整连接方式徒增一步。另外装完SQL Server记得开启TCP/IP协议默认实例端口1433别动否则客户端远程连不上。我在拆这个项目时还踩过一个版本玄学VS自带的LocalDBlocaldb实例名是(localdb)\MSSQLLocalDB而SQL Server Express的实例名是.\SQLEXPRESS连接字符串里如果写错一个斜杠报的错都是“建立到服务器的连接时发生错误”新手往往在这里卡很久。4.2 建库初始化执行SQL脚本或附加数据库文件源码包里有配套的SalesDB.sql建库脚本。打开SQL Server Management Studio用sa或有sysadmin权限的账号连上实例直接打开脚本文件执行一次InventoryDB库和五张表就会建好。脚本末尾还有初始化数据一个默认管理员账号admin密码123456、一个普通操作员operator以及几条测试商品记录。如果你拿到的是已附加的.mdf文件那就省事一点在SSMS里右键“数据库”节点选择“附加”选中.mdf文件即可。这里有个容易翻车的点.mdf文件路径不能放在中文路径或桌面SQL Server服务账号可能没权限读取导致附加时报“无法打开物理文件”。把数据库文件放到C:\Data\这类纯英文路径下能避开很多坑。建完库后用这条SQL快速验证表是否齐全SELECT name FROM sys.tables WHERE type U;应该能看到Users、Category、Product、InStock、OutStock五张表。执行失败时优先检查两点脚本是否被SSMS以“主库master”为上下文执行过、脚本开头的USE InventoryDB是否生效。4.3 改配置启动connectionStrings连接字符串的落地源码里连接字符串写在UI项目的app.config中connectionStrings add nameInventory connectionStringServer.;DatabaseInventoryDB;User IDsa;Password123456 / /connectionStringsServer.代表本机默认实例。如果SQL Server是Express实例改成Server.\SQLEXPRESS如果是远程服务器写成Server192.168.1.100,1433。密码就是安装SQL Server时设置的sa密码没有改过就用脚本里初始化的默认值。启动方式有两种你在VS里直接按F5程序会以Debug模式跑起来首次登录用admin/123456进主界面另一种是把项目发布到Debug目录后运行exe。需要注意Debug模式下app.config里的内容会被自动复制到Inventory.exe.config有时候你改了代码但运行还是旧连接串就是因为改了源文件里的config却没同步到输出目录。遇到这种情况直接删掉bin/Debug下的exe.config重新生成一次就好。第一次登录成功后建议立刻在“用户管理”里把admin密码改掉同时试试operator账号——它能看到出入库界面但没有用户管理权限这就是Role字段在起作用。4.4 打包部署Setup Project和配置文件外置交给别人用的时候不能总让人装VS。VS2017/2019需要先安装扩展“Visual Studio Installer Projects”然后新建一个Setup Project把UI项目的“主要输出”加进去再添加卸载程序编译后就得到一个Setup.exe的安装包。用户双击安装后Windows桌面会出现快捷方式。这里我个人强烈建议把app.config改成安装后还能编辑的形式。因为客户那边很可能换了SQL Server实例不可能为了改个连接字符串帮你重编译。常见做法是让程序启动时自动读取exe同目录下的config文件我已经在用这种写法// 从exe.config读取连接字符串允许部署时直接改文件 string connStr ConfigurationManager .ConnectionStrings[Inventory].ConnectionString;安装完成后去安装目录找到Inventory.exe.config用记事本改连接串即可。整个部署链路是装SQL Server → 执行建库脚本 → 装客户端安装包 → 改配置文件 → 双击启动。看起来步骤多但每步都只需要一次后续维护成本极低。5. 常见问题与避坑5个运行期高频翻车点5.1 连接字符串写死换台电脑就报“无法连接”现象在开发机上跑得好好的程序拷到另一台电脑双击exe就弹“建立到服务器的连接时发生错误”数据库连不上。原因是连接字符串里的Server指向的是开发机的实例名或IP换环境后自然找不到服务器。原因连接串被硬编码在代码里或者虽然写在app.config但没随程序一起发布。这套源码把连接串放在config里本意就是让你部署时改但很多二次开发者会忽略这一步。解决部署时先确认目标机器的SQL Server实例名Express版写.\SQLEXPRESS完整版写服务器IP,1433。其次确认SQL Server已启用混合验证模式sa密码正确。如果还连不上在命令行用telnet 192.168.1.100 1433看端口通不通。从那以后我每次拿到C/S项目都会先检查连接串是否外置再检查SQL Server端口是否对客户端开放。5.2 DataGridView列序乱套自动生成列把顺序打散现象给DataGridView设置DataSource后列的顺序变成字母序和你SQL里SELECT的顺序完全不一样比如先显示Stock再显示ProductName看着特别别扭。原因默认情况下DataGridView的AutoGenerateColumns为true它会按数据表的字段字母序自动生成列完全忽略SELECT语句里的书写顺序。这是新手最常吐槽的“控件不听指挥”问题。解决把DataGridView的AutoGenerateColumns设为false然后手动在Columns集合里添加列并把每列的DataPropertyName设为对应的字段名这样顺序就完全由你控制。我还习惯把商品号、数量、单价这类列的对齐方式设为右对齐数字列看起来更整齐。5.3 并发覆盖两个窗口同时入库把库存改错现象两个操作员同时按下“确认入库”结果其中一笔被覆盖库存只加了一次但流水表里却插了两条记录。这种情况在库存管理系统里属于严重数据事故。原因如果你在BLL里先SELECT Stock读到库存然后在内存里加一个数再UPDATE SET Stock 新值那并发场景下两个线程都读到同一个旧值后提交的人把先提交的人的结果覆盖掉了。解决不要在应用层算新库存让数据库来完成原子更新——SQL写成UPDATE Product SET Stock Stock qty WHERE ProductID pid。这个操作在数据库端是原子性的天然避免覆盖。配合第3.2节的事务包裹两条SQL就能保证流水和库存永远同步。5.4 明文密码拖库之后账号全线暴露现象数据库一旦被拖走或者被导出Users表里的密码直接就是原始字符串admin、operator等账号全部裸奔。原因建库脚本里初始化的密码是明文如果登录校验代码是WHERE Password password而不是比MD5值那存什么就是什么毫无安全性。有些二次开发图省事把登录SQL直接改成明文字段比较表面看逻辑没问题实际埋了个大雷。解决参考3.1节的做法注册和登录统一走MD5加盐。哪怕只是对原密码做一次MD5再入库也远比明文安全。还要注意如果已有明文数据改成MD5后老密码全部失效需要提供一个“重置密码为123456”的功能或者用UPDATE把旧密码批量刷成哈希值。5.5 日期转换失败字符串拼SQL的隐性雷区现象按日期范围筛选入库记录时用户在文本框输入“2024-06-01”还好输入“2024/06/01”或者“06-01-2024”就报“从字符串转换日期和/或时间时失败”程序直接崩溃。原因SQL语句里用字符串拼接了日期比如WHERE InDate txtStart.Text 数据库会根据自身的语言设置解析这个字符串不同格式的日期在不同区域设置下可能被解析成不同含义或者干脆解析失败。解决用参数化查询把日期作为DateTime类型传入SqlParameter让数据库自己处理类型转换。例如string sql SELECT * FROM InStock WHERE InDate startDate AND InDate endDate; SqlHelper.ExecuteQuery(sql, new SqlParameter(startDate, startPicker.Value), new SqlParameter(endDate, endPicker.Value));另外DateTimePicker控件直接取.Value属性就是DateTime类型没必要先ToString再转换中间多加一步就多一个出错机会。6. 二次开发手记从库存管理到进销存的三个方向6.1 挂上供应商和客户让出入库单据能追溯现在的入库单只存了一个Supplier字符串出库单也没有关联客户。要升级成进销存第一步是新增Customer表和Supplier表入库单的Supplier改成SupplierID外键出库单加上CustomerID。界面上的文本框换成ComboBox数据源绑定供应商/客户列表。这样做的直接收益是能按供应商统计采购金额、按客户统计销售贡献报表维度一下子丰富起来。6.2 报表图表化用Chart控件出30天库存趋势WinForms自带Chart控件不需要引入第三方图表库。改造时在MainForm加一个TabPage放Chart数据源用一个按天聚合的SQLSELECT CONVERT(VARCHAR(10), InDate, 120) AS Day, SUM(Quantity) AS TotalIn FROM InStock WHERE InDate DATEADD(DAY, -30, GETDATE()) GROUP BY CONVERT(VARCHAR(10), InDate, 120) ORDER BY Day;出库趋势用同样的方式查OutStock表Chart控件的Series设为Line即可。这个改动手感很好因为Chart控件直接把DataTable赋值给DataSource就能画出来半小时就能看到效果。唯一要留意的是X轴日期格式需要额外设置不然会显示成数字序列。6.3 权限细化从两角色到RBAC的设计变化现在只有Admin和Operator两个角色菜单的可见性靠登录后判断Role字符串。如果要做成多角色的RBAC则需要引入权限表、角色权限关联表并把当前用户可访问的菜单列表在登录时加载到GlobalCache里界面初始化时按权限动态生成菜单项。这个改造牵动面不小建议一步步来先导出“角色—菜单”矩阵再动数据库结构。做完后用两个不同角色的账号分别登录验证界面差异是否符合预期。从那以后我每次改造完权限或库存逻辑都会强制走一遍“登录两个账号做一次完整出入库、对一次账”的回归路径新手改这种项目最容易在权限判断里迷路。希望这些拆解和踩坑记录能帮到你让你的库存管理系统跑得比我的更稳。本文还有配套的精品资源点击获取
