1. .Net Framework时代的三层架构到 .NET 8 现代 Web API:面向高并发的系统演进思维
业务场景:用户登陆后,找到某个文件,下载时需要验证权限
界面展现层(UI-Presentation Layer):
.aspx和.aspx.cs,它们只负责接收用户的点击、拿文本框的值、把结果塞给网页控件、控制按钮隐藏
protectedvoidbtnDownload_Click(objectsender,EventArgse){// 1. 收集界面输入的数据stringfileId=hfFileID.Value;stringuserNo=Func.CurrentUser.User_no;// 2. 直接调用“业务逻辑层”的对象,问它能不能下载FileTypeInfoBllbll=newFileTypeInfoBll();boolcanDownload=bll.CheckDownloadPrivilege(userNo,fileId);// 3. 根据业务层的回传结果,只做“界面层”的操作if(canDownload){Response.Write("<script>alert('开始下载');</script>");}else{Response.Write("<script>alert('权限不足!');</script>");}}业务逻辑层(BLL-Business Logic Layer):
负责公司的“业务规章制度”(比如算考勤、算金额、判定各种复杂的权限逻辑组合)。它绝对不碰网页控件(如TextBox),也绝对不写SQL。
publicclassFileTypeInfoBll{publicboolCheckDownloadPrivilege(stringuserNo,stringfileId){// 核心业务规则:如果是系统管理员,直接放行if(userNo=="SYSTEM")returntrue;// 调用“数据访问层”去查这个文件的保密级别FileTypeInfoDaldal=newFileTypeInfoDal();stringfileLevel=dal.GetFileSecurityLevel(fileId);// 核心业务规则判断:如果是绝密文件(Level 4),普通人拒绝下载if(fileLevel=="4"&&userNo!="F8875675"){returnfalse;}returntrue;}}数据访问层(DAL - Data Access Layer):
纯粹和数据库(Oracle/SQL Server)打交道。写 SQL、连数据库、把查出来的DataTable丢给上层。它绝对不关心谁在调用它,也不关心这些数据拿去干嘛。
publicclassFileTypeInfoDal{publicstringGetFileSecurityLevel(stringfileId){stringsql="SELECT FILE_LEVEL FROM FILE_INFO WHERE FILE_ID = :fileId";// 这里执行原生的 ADO.NET 操作using(OracleConnectionconn=newOracleConnection(strConn)){using(OracleCommandcmd=newOracleCommand(sql,conn)){cmd.Parameters.AddWithValue(":fileId",fileId);conn.Open();returncmd.ExecuteScalar()?.ToString()??"0";}}}}核心意图:
如果未来有一天公司的数据库从Oracle迁移到SQL Server。但是SQL散落在几百个.aspx.cs页面里,工作量非常庞大。
而使用三层架构,只需要把DAL文件夹里的代码重新编写,而原本的.aspx界面代码不需要改动。这就是为了解耦和可维护性
2. 演进:向现代 .NET 8 架构(Controller-Service-Repository)迈进
控制器-服务-仓储模式 (Controller-Service-Repository)
现代化数据仓储层 (Repository - 替代原 DAL)
过去一直使用内存开销巨大的DataTable,引入ORM中间件Dapper,直接完成数据库C#强类型对象的映射
usingDapper;usingSystem.Data;publicinterfaceIFileRepository{// 使用异步编程提升系统的吞吐量Task<string>GetFileSecurityLevelAsync(stringfileId);}publicclassFileRepository:IFileRepository{privatereadonlyIDbConnection_dbConnection;// 数据库连接对象通过构造函数注入,避免在方法内部硬编码连接字符串publicFileRepository(IDbConnectiondbConnection){_dbConnection=dbConnection;}publicasyncTask<string>GetFileSecurityLevelAsync(stringfileId){conststringsql="SELECT FILE_LEVEL FROM FILE_INFO WHERE FILE_ID = @FileId";/* * 使用 Dapper 的 QueryFirstOrDefaultAsync 异步方法。 * 执行此查询时,当前 Web 线程会立刻释放回线程池去接收其他用户的 HTTP 请求, * 直到数据库返回数据,线程才会回来继续往下执行。这是高并发架构的核心基石。 */returnawait_dbConnection.QueryFirstOrDefaultAsync<string>(sql,new{FileId=fileId})??"0";}}现代化核心领域服务层 (Service - 替代原 BLL)
应用依赖倒置原则(Dependency Inversion Principle, DIP),业务层只认抽象接口(IFileRepository),不认具体的仓储类。
publicinterfaceIFileService{Task<bool>CheckDownloadPrivilegeAsync(stringuserNo,stringfileId);}publicclassFileService:IFileService{privatereadonlyIFileRepository_fileRepository;// 依赖注入:业务层只认接口,不认具体的仓储实现类,实现了高度解耦publicFileService(IFileRepositoryfileRepository){_fileRepository=fileRepository;}publicasyncTask<bool>CheckDownloadPrivilegeAsync(stringuserNo,stringfileId){if(userNo=="SYSTEM")returntrue;// 异步等待仓储层的数据库查询结果stringfileLevel=await_fileRepository.GetFileSecurityLevelAsync(fileId);// 执行核心权限规则判定if(fileLevel=="4"&&userNo!="F8875675"){returnfalse;}returntrue;}}现代化控制器层 (Web API Controller - 替代原 UI 页面)
前后端完全分离,丢弃.aspx和.aspx.cs,而是通过Web API各类前端容器(如 React/Vue)或微服务网关分发JSON数据。
usingMicrosoft.AspNetCore.Mvc;[ApiController][Route("api/[controller]")]publicclassFileController:ControllerBase{privatereadonlyIFileService_fileService;// 依赖注入:将业务服务注入到控制器中publicFileController(IFileServicefileService){_fileService=fileService;}/* * 遵循 RESTful 风格的现代化 HTTP API 接口。 * 前端通过发送如 GET /api/file/123/check?userNo=F8875675 的请求来触发此方法。 */[HttpGet("{fileId}/check")]publicasyncTask<IActionResult>VerifyDownloadPermission([FromRoute]stringfileId,[FromQuery]stringuserNo){// 调用底层的业务异步服务boolhasAccess=await_fileService.CheckDownloadPrivilegeAsync(userNo,fileId);if(!hasAccess){// 权限不足时,直接返回标准的 HTTP 403 状态码以及状态说明returnForbid("当前工号无权下载此级别的加密文件");}// 验证通过,向前端返回 HTTP 200 (OK) 状态码及 JSON 结果returnOk(new{CanDownload=true,Message="鉴权通过"});}}3. 架构演进的思维总结
对比这两套横跨了技术时代的架构实现,会发现:底层的框架、语法、技术中间件一直在快速迭代,但业务的核心本质(获取登录人身份、文件密级、能不能下载)从未发生改变。
在日常的代码审视与旧系统维护中,无需将精力陷于过时的页面生命周期语法,而应当在脑海中对旧代码的业务逻辑进行拆解与重构映射,将其归类为更具普适性的Repository、Service与Controller职责。这种抽象能力,正是保证代码在不同技术周期下都能优雅演进的核心底层思维。