企业官网建设流程全解析

简介：这是一套基于C#语言、采用ASP.NET技术开发的通用OA企业办公系统源码，基于.NET 4.0+框架构建，可在Visual Studio 2012与SQLServer 2008及以上环境部署，适合需要快速搭建或二次开发协同办公平台的企业信息化部门、开发人员和技术团队。系统覆盖个人办公、内部邮件、审批流程、公文收发、工作管理、知识文档、资产管理、培训记录、会议管理、车辆管理、图书管理、档案卷库、考试管理、会员管理、客户管理、进销存、项目管理、考勤管理、报表中心和系统管理等二十余项业务模块，并采用B/S架构，支持用户通过浏览器联网办公。资源中包含2002个文件，主要为C#及aspx源码、html页面、js/css前端脚本样式、数据库备份与日志文件、Web.config等配置文档，以及大量gif/png界面图标素材，压缩包大小约57.98MB，模块目录划分清晰。包内已提供默认管理员账号和数据库还原文件，可直接部署学习，也可作为企业级ASP.NET项目开发与功能扩展的参考。当前已有107人学习下载，适合用于各类OA系统的快速实施与实际项目落地。

1. 一套能跑的 C# OA 源码，省掉的不只是开发时间

做企业内部系统，我见过太多团队卡在同一个地方：业务部门催着要 OA，老板嫌商业版按人头收费太贵，自己从零写又没那个排期。这套基于 ASP.NET 的 C# OA 源代码，走的是 Visual Studio + SQL Server 这条最经典的路子，打开就能编译，附加数据库就能登录，人事、审批、公告、考勤这些高频模块都是现成的。它不是那种只有一个登录页的演示品，而是把企业办公里最占人力的流程管理部分做成了可改可拆的代码块。适合两类人：一类是刚接手公司内部系统的开发，需要一套能快速改造成自己公司流程的底子；另一类是还在用 WinForms 做进销存、想看看 ASP.NET WebForms 里权限和审批流是怎么落地的开发者。它的价值在于你能直接看到一套完整 OA 的表结构、权限模型和页面交互是怎么串起来的。

2. ASP.NET + SQL Server 的选型逻辑：为什么这套代码能一直改到今天

2.1 WebForms 的页面生命周期是理解这套代码的钥匙

打开这套源码，你会发现所有页面后缀都是.aspx，这是 ASP.NET WebForms 的标志。现在新项目都往 MVC 或 Core 上走，但 WebForms 有一个不可替代的优势：页面状态由 ViewState 自动维护。对于 OA 这种表单密集型系统，一个请假单从草稿到审批要跨多个回发操作，WebForms 的IsPostBack机制可以让你用最少的代码处理页面刷新和按钮点击事件。

打开Default.aspx.cs，你会看到典型的 Page_Load 写法：

protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // 首次加载时绑定部门下拉框和待办事项列表 BindDepartmentTree(); BindMyPendingTasks(); } }

IsPostBack是 WebForms 里最容易理解也最容易踩坑的属性。它判断当前请求是第一次加载（False）还是页面上的按钮触发的回发（True）。比如去重一个下拉框数据绑定，不判断的话每次回发都会重新绑定，用户刚选中的值就会被重置掉。在 OA 这种频繁提交表单的场景里，几乎所有页面的初始化逻辑都要包在这个判断里。

2.2 三层架构在源码里是怎么分的

整个解决方案结构非常标准，Model 层放实体类，DAL 层放 SQL 操作，BLL 层放业务规则，Web 层只负责接收请求和渲染页面。你随便打开一个模块，比如Models/LeaveRequest.cs，会看到实体类只有属性定义：

public class LeaveRequest { public int LeaveId { get; set; } public int EmployeeId { get; set; } public DateTime StartDate { get; set; } public DateTime EndDate { get; set; } public string LeaveType { get; set; } public int ApproverId { get; set; } public int Status { get; set; } // 0=草稿 1=审批中 2=通过 3=驳回 public string Remark { get; set; } }

对应的 DAL 层方法长这样：

public DataSet GetLeaveRequestsByEmployeeId(int employeeId) { string sql = "SELECT * FROM LeaveRequests WHERE EmployeeId = @EmployeeId ORDER BY CreateTime DESC"; SqlParameter param = new SqlParameter("@EmployeeId", employeeId); return SqlHelper.ExecuteDataset(sql, param); }

所有 SQL 都走统一的SqlHelper，连接字符串在Web.config里配置一次，全局生效。这套写法放在今天看有点过时，但好处是逻辑链路短，新接手的人从页面事件往下追三层就能看懂一条审批数据是怎么从数据库到界面的。

2.3 SQL Server 里的核心表结构：看懂这五张表就懂了一半 OA

把数据库附加进去后，重点看这几张表，它们是整个 OA 的骨架：

我一般会先看Sys_Role里的PermissionIds字段，它是用逗号分隔的菜单 ID 字符串。这种设计在中小型 OA 里非常常见——不建中间表，直接拼字符串。角色表里存着1,2,5,8这种值，登录时从 Session 里取出来 split 一下，就能判断当前用户能不能看到某个菜单项。优点是改权限快，缺点是权限粒度到不了按钮级。如果你要改造成按钮级权限，需要把这串 ID 解析逻辑换成真正的 RBAC 中间表。

3. 本地跑起来：VS 版本、SQL Server 配置和附加库的完整流程

3.1 环境选择：VS 2015 到 2022 都能编译，但要注意 Framework 目标

这套源码的目标框架是 .NET Framework 4.5 或 4.6。用 Visual Studio 2019 或 2022 打开.sln文件时，如果提示需要升级，选“不升级”，直接以原 Framework 版本编译。升级到 4.7 以上通常没问题，但升级后Web.config里的一些版本绑定可能需要手动加 bindingRedirect。

打开Web.config，核心配置在<connectionStrings>和<appSettings>：

<connectionStrings> <add name="OAConnectionString" connectionString="Data Source=.;Initial Catalog=OASystem;User ID=sa;Password=123456;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" /> </connectionStrings>

把Data Source改成你的 SQL Server 实例名。如果是本机默认实例就是.，如果是命名实例比如localhost\SQLEXPRESS就写全。User ID和Password按你的 SQL Server 登录账号改。MultipleActiveResultSets=True建议保留，OA 的页面经常在同一个连接上多次查询，关掉它可能在某些页面上报“已有打开的与此连接相关联的 DataReader”。

3.2 附加数据库的两种方式，推荐第二种

源码包里通常会带Database文件夹，里面有.mdf和.ldf文件或者.sql脚本。如果是.mdf文件，用 SQL Server Management Studio 附加：

1. 打开 SSMS，右键“数据库”节点，选择“附加”
2. 点“添加”，找到.mdf文件所在路径
3. 确认.ldf日志文件能被自动识别，点“确定”

如果附加时报权限错误，常见原因是 SQL Server 服务账号没有该目录的读取权限。把数据库文件夹放到C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA目录下再附加，能省掉一堆权限折腾。

如果是.sql脚本，用sqlcmd执行：

sqlcmd -S . -U sa -P 123456 -i D:\OA\Database\OASystem.sql

3.3 编译和启动：F5 跑起来之前先做这两件事

打开解决方案后，先右键解决方案选“重新生成解决方案”。如果报System.Web.Optimization或Newtonsoft.Json程序集找不到，说明 NuGet 包没有还原。右键解决方案，选“还原 NuGet 程序包”，等它下载完成再编译。

启动前确认 SQL Server 服务正在运行：

net start MSSQLSERVER

如果服务无法启动，打开 SQL Server 配置管理器，检查“SQL Server (MSSQLSERVER)”服务的状态。启动类型设为“自动”，登录身份建议用“内置账户”的 LocalSystem，避免用 NT Service 账号在某些目录权限上卡住。

做完这些，按 F5 启动 IIS Express，浏览器弹出登录页，用源码说明文档里的管理员账号登录。如果登录提示密码错误，直接去Sys_User表里把这个账号的Password字段改成e10adc3949ba59abbe56e057f20f883e，这是空字符串的 MD5 值，改完再用空密码登录。

4. 人事与办公核心模块实战：从登录权限到审批流的代码走读

4.1 登录逻辑里藏着 Session 和 Cookie 的处理细节

登录页面提交后走的是Login.aspx.cs里的btnLogin_Click事件，核心逻辑就三步：查用户、验密码、写 Session。

protected void btnLogin_Click(object sender, EventArgs e) { string userName = txtUserName.Text.Trim(); string password = Md5Helper.Encrypt(txtPassword.Text.Trim()); UserBLL userBll = new UserBLL(); DataTable dt = userBll.ValidateUser(userName, password); if (dt.Rows.Count > 0) { DataRow row = dt.Rows[0]; Session["UserId"] = row["UserId"].ToString(); Session["UserName"] = row["UserName"].ToString(); Session["RoleId"] = row["RoleId"].ToString(); // 写入登录日志 LogBLL.WriteLog(Convert.ToInt32(Session["UserId"]), "用户登录系统"); Response.Redirect("Main.aspx"); } else { lblMsg.Text = "用户名或密码错误"; } }

密码不是明文存储，Md5Helper.Encrypt做了一次 MD5。这套源码的密码策略比较基础，如果你要部署到生产环境，建议至少改成 MD5 加盐或者直接换 SHA256。Session 是整个权限体系的承重墙，所有页面的权限判断都从这里取值。注意这段代码里没有写 Cookie 持久化登录，所以 IIS 回收或 Session 超时后用户会被踢回登录页——OA 使用频率高，建议在Web.config里把 Session 超时时间调大：

<system.web> <sessionState mode="InProc" timeout="120"></sessionState> </system.web>

4.2 人事档案模块：文件上传和数据回显的常规操作

人事模块是 OA 里数据项最多的部分。打开EmployeeManage.aspx，它的核心是一个 GridView 列表加一个编辑弹窗。添加员工时包含照片上传，处理方式是把图片存到UploadFiles目录，数据库只存相对路径：

protected void btnSave_Click(object sender, EventArgs e) { string photoPath = ""; if (fileUpload.HasFile) { string ext = System.IO.Path.GetExtension(fileUpload.FileName); string fileName = DateTime.Now.ToString("yyyyMMddHHmmss") + ext; string savePath = Server.MapPath("~/UploadFiles/") + fileName; fileUpload.SaveAs(savePath); photoPath = "UploadFiles/" + fileName; } EmployeeBLL bll = new EmployeeBLL(); bll.AddEmployee(txtName.Text, txtDept.SelectedValue, txtPosition.Text, photoPath); }

文件上传的核心是Server.MapPath，它把虚拟路径~/UploadFiles/映射成服务器物理路径。这里有一个非常隐蔽的坑：IIS Express 默认运行在localhost下，上传的文件会保存到项目目录里的UploadFiles文件夹，但如果是部署到正式的 IIS 服务器，这个目录必须给IIS_IUSRS用户写入权限，否则SaveAs直接抛“拒绝访问”异常。

4.3 审批流的设计：节点配置加实例表的双表结构

OA 的审批流是整个系统里最值得读的代码。设计上分两块：流程定义表OA_Workflow里存“这个请假单要走几个节点”，审批实例表OA_WorkflowInstance存“这张单现在走到哪一步了”。

public bool SubmitLeaveRequest(int employeeId, int workflowId, string formData) { using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlTransaction tran = conn.BeginTransaction()) { try { // 1. 创建审批实例，当前节点指向流程的第一个节点 SqlCommand cmd = new SqlCommand(@" INSERT INTO OA_WorkflowInstance (WorkflowId, ApplicantId, CurrentNodeId, Status, CreateTime) VALUES (@WorkflowId, @EmployeeId, 1, 1, GETDATE())", conn, tran); // 2. 插入申请单数据到业务表 SqlCommand cmd2 = new SqlCommand(@" INSERT INTO LeaveRequests (EmployeeId, StartDate, EndDate, LeaveType, Remark, InstanceId) VALUES (@EmployeeId, @StartDate, @EndDate, @LeaveType, @Remark, SCOPE_IDENTITY())", conn, tran); cmd.ExecuteNonQuery(); cmd2.ExecuteNonQuery(); tran.Commit(); return true; } catch { tran.Rollback(); return false; } } } }

这段代码我拆一下设计意图：事务保证审批实例和业务单据同时生效，不会出现“单子提交了但审批流没建起来”的脏数据。SCOPE_IDENTITY()拿到的自增 ID 被写进业务表作为外键关联，这样审批流只存流程状态，业务数据留在各自的业务表里。如果你要加一个“出差申请”模块，复制这段逻辑，把业务表换成出差表，审批流直接复用。

5. 部署与二次开发中的避坑记录：五个真实翻车现场

5.1 数据库附加后登录报“找不到存储过程”

现象：附加数据库后能打开登录页，输入管理员账号点登录，页面报“找不到存储过程 dbo.Proc_UserLogin”。

原因：源码包里带的是完整数据库备份，但附加的时候只挂了.mdf，部分数据库对象没有同步。

解决：确认附加时.ldf日志文件也在同一目录。如果还不行，用一个干净的库重新执行Database目录下的初始化 SQL 脚本。我一般新建一个空数据库，直接跑.sql脚本，不用附加流程。

5.2 页面样式加载不出来，所有 CSS 都是 404

现象：登录页能打开，但整个页面没有样式，F12 看控制台全是.css404。

原因：源码里用了BundleConfig，CSS 通过System.Web.Optimization统一打包输出。本地运行没问题，但部署到 IIS 后没有启用静态文件处理模块。

解决：Web.config里确认以下配置存在：

<system.webServer> <modules runAllManagedModulesForAllRequests="true" /> <staticContent> <mimeMap fileExtension=".css" mimeType="text/css" /> </staticContent> </system.webServer>

runAllManagedModulesForAllRequests是让所有请求都走 ASP.NET 管线，这样打包后的 CSS 路径才能被正确解析。加完配置重启站点即可。

5.3 上传文件后头像不显示，图片路径少了一个斜杠

现象：员工头像上传成功，但页面上图片裂了，查看 HTML 发现src是UploadFiles/xxx.jpg。

原因：数据库存的路径是UploadFiles/xxx.jpg，页面绑定时直接用了这个值，没有加前导/，导致浏览器把当前页面的虚拟目录路径拼了上去。

解决：在绑定图片时强制补全路径：

string photoPath = row["PhotoPath"].ToString(); if (!string.IsNullOrEmpty(photoPath) && !photoPath.StartsWith("/")) { photoPath = "/" + photoPath; } imgPhoto.ImageUrl = photoPath;

5.4 多人在线时 Session 丢失，用户被反复踢回登录页

现象：系统上线后，部分用户操作几分钟就提示登录超时，重新登录后很快又掉线。

原因：Session默认存在进程内，IIS 应用池回收后 Session 全丢。更隐蔽的是，代码里有多处直接给 Session 赋值为空字符串或 null，比如退出登录时只清了一个键，其他页面读取时判断不完整。

解决：第一，应用池的“回收时间”从默认的 1740 分钟改成 0 或改大；第二，检查所有退出相关代码，用Session.Abandon()统一清理：

protected void btnLogout_Click(object sender, EventArgs e) { Session.Abandon(); Response.Redirect("Login.aspx"); }

5.5 修改 Web.config 后站点立即重启，用户全掉线

现象：给 Web.config 加了一个连接字符串，保存后所有在线用户全部掉线。

原因：ASP.NET 对 Web.config 的改动会触发应用域重启，这是平台机制。很多人为了改个配置频繁保存，导致线上用户反复被踢。

解决：连接字符串这类高频改动的配置，我习惯放到Web.config外部的独立文件里：

<connectionStrings configSource="connections.config"></connectionStrings>

connections.config里直接放<connectionStrings>节点内容。这样改连接字符串只影响读取该文件的请求，不会触发整个应用池重启。

6. 从这套 OA 源码延伸：我如何把一个请假单改成加班申请单

假如现在业务部门提出要加一个“加班申请”模块，完全可以在不触碰原有代码的前提下，照着请假模块的路径做一套。我实际做过一次，流程是：先复制LeaveApply.aspx和.cs文件，改名OvertimeApply.aspx，页面上的字段标签换成加班起止时间、加班事由、预计时长。然后修改提交按钮的代码，把插入目标从LeaveRequests换成新建的OvertimeRequests表。

关键的地方在于审批流那一块，请假单走的是WorkflowId = 1的流程，加班单可以新建一条流程，在OA_Workflow表里插入一条OvertimeWorkflow记录，节点配置按“部门主管审批 → 人事复核”两个节点设。这样审批逻辑代码一行都不用改，靠 WorkflowId 区分就能跑通。这个过程验证了你对这套源码的掌握程度：表结构、页面事件、Session 权限取法和事务提交逻辑，每条链路都走得通。

从那以后，我每次改动这套源码都会先花十分钟梳理一个问题的答案：数据流从页面到数据库要经过几层、Session 里存的用户信息在哪几个页面被读取、哪些表是业务表哪些表是流程表。把这几个问题在文档里写清楚，再动手改代码，翻车概率会大幅下降。希望这套源码的拆解能让你少走几个弯路。

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