简介客户关系管理CRM系统是企业信息化建设中的核心应用其业务模型围绕线索、商机、合同与回款形成完整闭环。在传统.NET技术栈中ASP.NET WebForms搭配ligerUI、SQL Server及IIS部署曾是后台管理系统的主流方案通过一般处理程序.ashx返回JSON实现前后端数据交互这一模式与现代Web API的设计思想一脉相承。理解这套源码不仅能快速搭建CRM原型还能为老项目维护和二次开发提供可直接复用的业务骨架。实际落地中从Excel数据导入、业绩看板到多租户SaaS化改造都需要对原有数据模型与权限体系进行梳理。面对基于ASP.NET Core的现代化升级需求可保留业务模型与数据库设计逐步替换WebForms界面实现渐进式迁移。掌握这些技术要点有助于开发者在实际工程中高效交付客户管理系统。ASP.NET客户关系管理系统源码别急着删这是拿来即用的业务骨架我敢说不少人的硬盘里都躺着这么个压缩包“ASP.NET客户关系管理系统源码大型CRM源码ASP.NET源码ligerUI框架.zip”。从论坛扒下来的或者网盘分享转存的下载完了就一直吃灰。实际上这套东西极有学习价值——它代表了一个非常典型的“传统.NET技术栈成熟业务模型”的组合。如果你现在在做毕业设计、接手老项目的维护或者想在CRM这个业务方向上快速搭个原型这套源码就是最好的地基。它能让你在一小时内看到“客户、联系人、跟进记录、商机、合同、回款”这一整条销售闭环的真实落库方式以及一个老练的ASP.NET站点是怎么组织前端资源和后端代码的。写这篇文章不是让你把压缩包解压完就关了。我会从这套源码里最核心的业务设计讲起拆开ligerUI这个看似过时但实际很高效的UI框架然后把部署到IIS的完整流程“手把手”给你过一遍。中途会穿插大量我实际踩过的坑和改过的代码希望你能直接抄作业而不是拿着源码再脑补三小时。1. 这套CRM源码到底讲了一个什么故事1.1 CRM的核心从来不是“客户表”而是业务闭环拿到源码先别去看页面外观先去后台上把数据库关系理清楚。典型的ASP.NET客户关系管理系统核心不是客户表本身而是围绕客户产生的一整条业务链线索Lead→ 客户Customer→ 联系人Contact→ 商机Opportunity→ 合同Contract→ 回款Payment。这套源码里通常也是这个结构。你可以把线索理解成“还没确认的潜在客户”一旦电话或拜访里确认了对方有意向就把线索转为客户客户下面挂着若干个联系人联系人是谁跟你谈、谁管报销、谁拍板商机则是具体的销售机会比如“这个客户3个月内有采购计划”商机里面有预计金额、预计成交时间、销售阶段初访、意向、报价、谈判、赢单等合同签了商机就变成了合同合同再关联到回款计划。提示判断一个CRM源码质量怎么样不要只看它能录入多少字段而是看它有没有把“客户状态”和“商机阶段”串成一个可追踪的流程。如果源码里只有一张客户增删改查的表那不管界面做得多华丽严格来说都不算CRM。这套源码我建议大家重点看三张表客户表通常叫Customer或者Crm_Customer、跟进记录表FollowRecord或者Crm_Follow、商机表Opportunity。跟进记录是整个CRM的信息枢纽任何一次电话、拜访、微信沟通都应该能在客户详情页里按时间轴拉出来。源码里如果用了单独的记事本式的表来记录那这个系统的思路是对的。1.2 模块划分从菜单反推业务边界源码解压之后看它的母版页或者顶部导航菜单就能反推出业务模块的划分方式。传统ASP.NET的CRM项目里菜单基本长这样客户管理客户列表、客户池、分配/转移、回收站销售管理商机列表、跟进计划、合同管理、回款管理市场营销市场活动、线索管理系统设置用户、角色、权限、数据字典、操作日志每个模块背后对应的是一个独立的目录和页面集合。这种“菜单即模块边界”的思路在今天看依然非常清爽。你看源码时不要被一大摞.aspx文件吓住先按菜单分组归类每一组是一个相对独立的业务域彼此之间通过客户ID或商机ID关联。这种做法在今天做微服务拆分时也很有参考价值——菜单就是天然的Bounded Context。比如“客户管理”和“合同管理”虽然有数据关联但它们各自的业务规则是独立的。你未来如果要把这套系统二次开发成分布式架构先按菜单模块拆分服务就是个零成本起步的方案。2. 为什么偏偏是ligerUI传统ASP.NET前端的现实选择2.1 ligerUI的核心组件与真实使用体验ligerUI是一套基于jQuery的国产开源UI组件库发布已经很多年了。今天看它的默认皮肤可能有一点年代感但千万别因此低估它。在ASP.NET WebForms时代ligerUI几乎是效率最高的后台界面方案之一因为它把表格、表单、弹窗、树、菜单这些后台管理系统的常客全部封装好了。这套源码里你用到的组件大概就这几样ligerGrid表格组件负责列表展示、分页、排序、列隐藏、行选择ligerForm表单引擎用JSON配置自动生成表单少写大量HTMLligerDialog弹窗配合表单用来做新增、编辑ligerTree树形结构常见于部门/权限/客户分组ligerTab标签页用于把多个功能页组织在一个工作区里ligerGrid是这套系统的门面。打开客户列表页数据加载走Ajax请求一个一般处理程序.ashx或WebService返回JSON数据ligerGrid负责渲染。你在源码里会看到类似这样的初始化代码$(function () { grid $(#maingrid).ligerGrid({ url: CustomerHandler.ashx?actionquery, parms: getSearchParams(), columns: [ { display: 客户名称, name: CustomerName, width: 200 }, { display: 客户等级, name: Grade, width: 80 }, { display: 联系人, name: Contact, width: 100 }, { display: 电话, name: Tel, width: 120 }, { display: 创建时间, name: CreateTime, width: 140 } ], pageSize: 20, rownumbers: true, checkbox: true }); });这一段代码很好地体现了ligerUI的设计哲学把列定义、数据源、分页行为交给你配置渲染细节它全包了。上手成本非常低你只要会写JS对象字面量基本就能把表格用起来。2.2 ligerUI的优势和“坑”我两分钟全说完ligerUI最大的优势是源码开放、文件纯粹。压缩包里就是几个js和css文件引入就能用没有复杂的模块化依赖、没有npm生态的泥石流。对于内网部署、离线办公、传统IT环境的项目来说这种“下载即用”的体验反而成了一等优势。但它也有几个明显要注意的地方依赖jQuery版本ligerUI 1.x比较老部分组件在jQuery 1.9之后有些小问题比如.live()方法被移除。很多源码包里带的jQuery是1.7或1.8尽量别手欠去换版本换了可能引发一堆诡异bug。皮肤定制费劲默认样式是蓝色系你要是想改成其他主题色要么覆盖css要么改ligerUI源码里的less变量工作量不小。表格渲染大数据量有压力ligerGrid一次性渲染几百行没问题但如果上千行而且每行都有按钮页面就会明显卡顿。处理方式是强制开启分页把pageSize控制在50以内。实操心得改ligerUI样式时不要直接改它的核心css文件。新建一个skin.css用更高优先级的选择器去覆盖。这样将来升级ligerUI版本时你的自定义样式不会被冲掉。2.3 ASP.NET WebForms Ajax JSON 的数据交互模式这套源码里前端和后端通信采用的模式很值得学前端用jQuery的$.ajax或$.post把请求发到一个通用处理器后端返回JSON字符串前端再渲染。虽然WebForms页面本身有ViewState和PostBack机制但在ajax交互场景里一般处理程序.ashx反而更轻量、更主流。翻开源码里的一个handler它内部的逻辑通常是public class CustomerHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { string action context.Request[action] ?? ; string result ; switch (action) { case query: result QueryCustomers(context); break; case add: result AddCustomer(context); break; case update: result UpdateCustomer(context); break; case delete: result DeleteCustomer(context); break; } context.Response.Write(result); } }这种写法在现代前后端分离项目里被重新包装成了“统一API入口”本质上是一样的思路。你说它古老吧它不过时的点恰恰在这——今天你用ASP.NET Core写Web API也是类似的action分发只是换成了更优雅的特性路由。所以看这套源码不是考古是在看设计模式的源头。3. 从解压到跑起来部署这台CRM的完整实操3.1 环境清单一顿操作前先对好版本拿到这套源码第一件事不是急着双击.sln而是确认环境。传统ASP.NET的版本差异、IIS配置差异、数据库版本差异任何一个不匹配都能让你白忙活一下午。常见需要的环境如下项目推荐环境说明操作系统Windows 10/11 或 Windows Server 2016部署到Linux暂时别想传统ASP.NET高度绑定Windows/IISIDEVisual Studio 2015/2017/2019如果源码是低版本的WebApplication高版本VS通常能自动升级但有概率出现兼容问题.NET Framework4.5 或 4.6.1看项目文件(TargetFrameworkVersion)确认数据库SQL Server 2008R2/2012/2014/2016/2019大部分源码包默认给的是SQL Server脚本浏览器Chrome/EdgeIE模式备用ligerUI对现代浏览器基本兼容但老版本IE有历史包袱IISIIS 7.5以上Win10/Server上需要添加ASP.NET功能如果解决方案打开后提示“无法加载项目”可以试着一招不要双击.sln用记事本打开.csproj检查TargetFrameworkVersion里面写的版本号。然后去Visual Studio Installer里安装对应的.NET Framework开发工具包绝大多数问题都能解决。3.2 数据库脚本找对文件按顺序执行数据库脚本通常放在源码根目录下的Database或SQL文件夹里常见文件名叫db_crm.sql、crm_init.sql、data.sql。这里有个细节要特别注意有些源码包把建表脚本和初始化数据脚本分成了多个文件而文件之间没有自动执行顺序说明。你盲目全部执行一遍反而可能会因为外键约束导致报错。最稳妥的顺序是先执行建库脚本如果有独立的CreateDatabase.sql再执行建表脚本通常文件体积比较大包含表结构最后执行数据初始化脚本插入管理员账号、数据字典、示例客户执行方式很简单打开SSMS新建查询把.sql文件的内容粘贴进去执行。如果SQL文件特别大几十MB用命令行的方式更快sqlcmd -S . -d master -i D:\CRM\db_crm.sql注意如果SQL脚本里包含了USE [CrmDB]这样的语句执行前先确认目标实例上有没有同名数据库防止覆盖掉已有的库。数据库执行完先去看一眼Sys_User表里的管理员账号。大部分源码默认账号是admin密码是admin或者123456少数会有加密后的密码。如果表里存的是密文那就在源码里搜一下“Md5”、“Encrypt”、“DES”这些关键词找到加密方式。通常就是MD5(md5(password) salt)这种老套路。3.3 Web.config配置连接字符串是第一个命门用VS打开项目直接找到Web.config文件重点看connectionStrings节点。类似这样connectionStrings add nameCrmConnectionString connectionStringData Source.;Initial CatalogCrmDB;User IDsa;Password123456;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStrings你需要把Data Source改成你的数据库实例名User ID和Password改成能登录的数据库账号。要不要用sa账号如果只是本地测试问题不大如果放到测试服务器建议创建一个专用账号只授予CrmDB的db_owner权限。这里有个容易踩的坑如果数据库账号密码里有特殊字符比如、#、在连接字符串里可能需要转义或者直接报“关键字不支持”的错。最简单的办法是避免在密码里用这些字符或者用代码动态构建连接字符串。改完保存按F5跑一下。如果弹出登录页说明站点启动成功。3.4 IIS部署从本地到服务器的关键一步本地跑通只是第一步。真实项目里你大概率要把这套源码发布到一台Windows Server上。这时候别再用VS自带的IIS Express了直接用正式IIS。发布方式有几种我建议最稳妥的做法在VS里右键项目选择“发布”目标选“文件夹”输出到D:\publish\crm在目标服务器上打开IIS管理器右键“网站”添加网站物理路径选D:\publish\crm端口绑定开发环境随便选8080、8090生产环境用80或443应用程序池“.NET Framework v4.0” “集成”模式如果你在服务器上打开页面看到错误“无法加载文件或程序集System.Web.HttpWebControls”或者类似缺失程序集的报错多半是bin目录没有把依赖的DLL带全。最简单的办法是本地bin目录整个复制过去不要一个个挑。实操心得IIS部署完打不开页面先打开“服务器管理器 → 工具 → 事件查看器 → Windows日志 → 应用程序”看有没有.NET运行时错误。很多时候IIS页面只报一个笼统的500详细错误全在事件日志里。3.5 项目目录结构这套源码的代码组织方式这类源码的项目目录通常长这样App_Code如果网站类型是WebSite或者普通文件夹如果是WebApplicationAuth/Handler—— 放一般处理程序和权限验证Css/Js—— 样式和脚本ligerUI相关文件都在里面Pages/Modules—— 各业务页面Web.config—— 配置核心Global.asax—— 程序启动事件看代码的入口建议从Global.asax或App_Code下的公共类看起。比如一个典型的BasePage.cs里面会封装权限判断大部分页面继承它。public class BasePage : System.Web.UI.Page { protected override void OnLoad(EventArgs e) { if (Session[UserId] null) { Response.Redirect(Login.aspx); return; } base.OnLoad(e); } }看懂这个基类你就知道为什么页面上到处都有CheckLogin()这样的代码了。新增页面时继承BasePage就自然带上了鉴权逻辑。这套设计看似简单但对于业务系统非常实用。4. 别只会部署二次开发才是这套源码的真正价值4.1 最常用的10个二次开发场景一套CRM源码拿到手不是让你原封不动用的。实际业务里最常见的二次开发需求我列个清单你可以对照自己手里的源码评估工作量客户导入导出从Excel导入客户导出一份客户列表数据看板首页放一个图表显示商机漏斗、销售业绩、跟进统计消息提醒当天待跟进客户弹窗提示操作日志记录谁在什么时间改了什么数据自定义字段在客户表和商机表里扩展字段审批流程合同需要上级审批后生效权限细化销售只能看自己的客户销售总监能看全公司的回收站机制删除客户不是物理删除而是进入回收站可恢复去重机制新增客户时按公司名称或手机号查重移动端适配页面在手机上能正常显示这些需求里最急迫、也最能练手的是“客户导入导出”和“首页数据看板”。下面我拿这两个来举例。4.2 实操1Excel导入客户功能的实现思路Excel导入功能是所有CRM必谈的需求。ASP.NET WebForms时代常见的方案是用NPOI库读取Excel这个库的好处是绕开了Excel COM组件的坑不需要服务器装Office。实现思路三步走第一步在页面加一个上传控件把Excel文件保存到服务器的临时目录。第二步服务端读取Excel数据逐行校验把合法数据插入客户表非法数据返回错误信息。// 用NPOI读取Excel第一张表 using (FileStream fs File.OpenRead(filePath)) { IWorkbook workbook new XSSFWorkbook(fs); ISheet sheet workbook.GetSheetAt(0); for (int rowIndex 1; rowIndex sheet.LastRowNum; rowIndex) { IRow row sheet.GetRow(rowIndex); if (row null) continue; string customerName row.GetCell(0)?.ToString(); string phone row.GetCell(1)?.ToString(); if (string.IsNullOrEmpty(customerName)) { errors.Add($第{rowIndex 1}行客户名称为空); continue; } // 调用DAL层写入数据库 } }第三步给客户返回“导入成功X条失败Y条”的汇总信息并且提供失败原因下载。没有把失败原因明细给用户的导入功能后面一定会被投诉。4.3 实操2给首页加一个销售业绩看板很多老CRM源码的首页就是一格一格的待办列表没有任何图表。现在你打开它的首页代码在合适的位置加两个Chart控件或者直接用ECharts画图。由于前端已经加载了jQuery和ligerUI它们和ECharts不冲突你只要引一个ECharts的js文件就能开干。举例要做一个“本月各销售员回款金额排行”的柱状图后端写一个handler查询分组汇总数据public string GetSalesRank() { string sql SELECT TOP 10 SalesName, SUM(PaymentAmount) AS TotalAmount FROM Crm_Payment WHERE PaymentDate startDate AND PaymentDate endDate GROUP BY SalesName ORDER BY TotalAmount DESC; DataTable dt DbHelper.ExecuteDataTable(sql, new SqlParameter(startDate, monthStart), new SqlParameter(endDate, monthEnd)); return JsonConvert.SerializeObject(dt); }前端用ECharts渲染$.post(ReportHandler.ashx?actionsalesRank, function (data) { var rows JSON.parse(data); var names rows.map(function (r) { return r.SalesName; }); var amounts rows.map(function (r) { return parseFloat(r.TotalAmount); }); var chart echarts.init(document.getElementById(rankChart)); chart.setOption({ xAxis: { type: category, data: names }, yAxis: { type: value }, series: [{ type: bar, data: amounts }] }); });这样首页从“静态待办”变成“数据看板”向领导汇报的时候观感完全不一样。而且这套改造过程里你会顺便把这家公司的数据模型重新摸了一遍比看十遍文档都管用。4.4 老系统的“现代升级”路线迁移到ASP.NET Core的思考看热搜词里频繁出现ASP.NET Core 9、远程验证remote、SAAS源码这些词说明不少人在思考怎么把老系统迁移到新平台。我这里给你一个相对务实的路线图。老ASP.NETWebForms到ASP.NET Core的迁移不是简单换汤不换药而是整体重构。老项目里的aspx页面、ViewState、服务器控件、.ashx handler在ASP.NET Core里全部没有对应物。合理的迁移分四步走梳理业务逻辑层BLL把老项目里写在代码后置页面的业务逻辑抽取成独立服务类这是纯C#代码理论上可以直接复用或复制到新项目。数据访问层替换老项目用ADO.NET或者SqlHelper的老套路在新项目改为EF Core或Dapper。表结构不用动数据模型类可以按表映射。页面重写aspx页面改成Razor页面或者Razor类库后端接口用Controller替代。原本ligerUI管理的表格可以考虑换成Vue/React Element UI但这步工作量最大。认证与权限老的Session认证改造成JWT或Cookie认证权限模型可以沿用RBAC设计。个人建议如果只是维护需求老系统继续跑完全没问题。如果确实要升级优先做“业务服务化”先把BLL拆出来做独立类库再考虑UI重写。千万别一上来就把页面重写了那样项目战线拉长风险不可控。4.5 SaaS化与多租户方向这套源码能不能撑住热搜词里还有“crm saas 源码”说明行业里对SaaS化的CRM源码也有需求。传统ASP.NET的CRM改成SaaS模式核心是解决“多租户数据隔离”。老系统通常是单租户表结构里没有TenantId这个字段改成SaaS要做两件事方案A独立数据库—— 每个租户一个数据库老代码几乎不用改但运维成本线性增加适合客户规模大的场景。方案B共享数据库、行级隔离—— 每个Customer表增加TenantId字段所有查询强制加上租户过滤条件这是最省资源的方案但需要对老代码做比较全面的改造。单从这个源码的结构看方案B做起来难度不小因为它大量SQL写在业务逻辑里如果漏掉一个查询条件数据就越权了。所以老项目上SaaS我建议优先考虑方案A先用自动化脚本完成“按租户建库、执行脚本、分配连接字符串”的流程比硬改代码安全得多。5. 从部署到上线常见问题与排查技巧5.1 站点打不开、500错误、404错误对应怎么处理你部署的时候一定会遇到问题我给你一份速查表现象大概率原因解决办法页面打不开浏览器提示“无法访问”IIS站点未启动绑定端口被占用应用池停止检查IIS站点状态换端口重启应用池提示500内部服务器错误web.config语法错误DLL缺失程序集版本不对先看事件查看器日志定位具体异常提示“请求的内容似乎脚本”或纯文本ASP.NET未注册到IIS管理员运行aspnet_regiis -i或者安装IIS的ASP.NET功能404但文件确实存在集成模式/经典模式不匹配路由配置问题试着切换应用池模式或者检查Web.config里的system.webServer数据库连接超时连接字符串服务器名不对防火墙挡了1433端口账号密码错误在服务器上用SSMS测试连接确认能连再跑程序页面乱码编码不一致老项目多为繁体或者GB2312检查web.config里globalization节点的fileEncoding和requestEncoding5.2 ligerGrid表格不显示数据90%是JSON格式问题ligerGrid接口返回的数据格式要求很严格它默认需要指定total和Rows字段。你在源码里会看到handler里有一段类似这样的代码var result new { total totalCount, Rows listData }; return JsonConvert.SerializeObject(result);如果表格不显示数据先把接口返回的JSON字符串打印出来看一眼十有八九是字段名对不上。注意Rows这个单词在ligerGrid里默认首字母是大写的如果你返回的是rows那怎么调都调不出来。可以在ligerGrid初始化时加一个参数$(#maingrid).ligerGrid({ url: CustomerHandler.ashx?actionquery, dataAction: server, pageSize: 20, root: Rows, // 指定数据行字段名 record: total // 指定总数字段名 });这两个参数能解决绝大多数“接口有数据但grid空白”的诡异问题。5.3 登录后Session丢失、频繁被踢下线老ASP.NET项目默认Session存内存应用池一旦被回收所有Session全部清零。如果你部署后频繁被踢下线从这三个方向排查应用池回收时间打开IIS的应用程序池选择“应用程序池默认设置”把“空闲超时分钟”调整到0或较大的值默认20分钟的超时时间非常容易造成Session消失。调整“固定时间间隔(分钟)”将回收周期改大比如2880分钟。重启会话可能你开发机器上没问题但服务器上内存不足导致工作进程重启升级内存或限制SQL Server占用。Cookie域名问题若部署在二级域名或端口下注意web.config里的httpCookies域名设置不要轻易写死域名。system.web httpCookies httpOnlyCookiestrue requireSSLfalse sameSiteLax / /system.web经验之谈老系统的Session访问量大时性能并不好。如果你二次开发的范围比较大可以考虑把Session持久化到数据库或Redis里但这一步复杂度高初期没必要做。5.4 一台服务器部署多个CRM实例的注意事项很多人一台服务器上跑多个老系统踩过的坑我顺手列出来端口分开每个站点用不同端口避免端口冲突应用池独立两个站点共用同一个应用池的话一个站点崩溃会导致另一个也挂数据库隔离数据量不大时可以用同一个实例但库名和账号分开防止连接串串了文件权限有的CRM需要写入上传目录比如Upload、ExcelTemp要给应用程序池账号分配写权限否则上传功能会报“对路径的访问被拒绝”5.5 老代码里的“隐形炸弹”与性能建议这套源码里常见的隐患一是SQL注入部分页面可能用字符串拼接SQL二是ViewState膨胀页面状态数据量过大三是图片上传无限制容易把磁盘撑爆。如果是自用内网问题不大如果暴露在公网务必先做一轮代码审计。性能建议方面我一般不推荐一上来就搞分布式先把最简单的做了客户列表查询加上索引尤其CustomerName、CreateTime、OwnerUserId这些常用过滤字段给大列表页开启合理分页别用一次加载全部再前端分页的模式静态资源ligerUI的js/css开启浏览器缓存减少重复下载SQL查询执行计划检查一遍大表上面尽量避免LIKE %关键词%的写法-- 推荐给客户表常用查询条件加索引 CREATE NONCLUSTERED INDEX IX_Customer_Owner ON Crm_Customer(OwnerUserId, CreateTime DESC) INCLUDE (CustomerName, Tel, Grade);加了索引之后客户明细页的查询速度通常情况下能提升一个数量级。6. 升级到ASP.NET Core哪些老代码可以带走哪些必须扔掉前面多少提到迁移工作了。我猜不少读者跟我一样接到过“能不能把这套CRM搬到Core上”的需求。真动手的时候你会发现自己面临的是一个“部分保留、整体重构”的工程。可以带走的是业务模型、数据库设计、流程设计、权限模型。这些是系统真正的资产跟技术栈无关。比如“跟进记录 商机阶段 回款”这套CRM核心模型在ASP.NET Core里照样能用只是传输方式从aspx页面PostBack变成了Web API加JSON。必须扔掉的是WebForms的生命周期、ViewState、服务器控件、aspx页面本身、基于IHttpModule的管道处理逻辑。如果你决定迁移我建议第一次做的时候选一个模块当试点比如“客户管理”从登录到列表再到新增编辑完整走一遍。这样做的好处是你会把老代码里涉及到的所有坑都踩一遍比如加密算法迁移、文件上传路径处理、分页SQL改写。试点做完剩下模块的工作量就有谱了。7. 这套源码的未尽话题从单机老系统到现代应用改造说到这套源码我还想多聊一个相对宏观的话题它到底还有没有未来我的观点是这类老系统不会立刻消亡因为它的业务逻辑成熟、稳定很多企业内部运转真的就是靠它。你要做的不是劝老板推倒重来而是想办法让它“苟住”同时渐进式现代化。保守派路线是保留现有ASP.NET站点不动在它旁边新建一个ASP.NET Core的API项目把一些新增的移动端、报表、数据大屏功能挂在API上老系统通过WebRequest调用新API。这种方式改动最小风险最低。激进派路线是把整套系统拆拆拆先拆出数据层Dapper/EF Core再拆出认证中心最后把老页面全部替换成前后端分离。这套路看起来美好但实际上对团队能力要求极高而且周期很长。我个人在实际操作中的体会是代码的现代化是手段业务价值才是目的。如果一套源码能帮你在一天内跑通客户管理的完整闭环那它对你来说就是无价的。技术老不老根本不重要。放个心态打开zip的那一刻不要指望它是个完美的产品它只是一个起点。真正值钱的是你把它看懂、改对、用起来的那双手。本文还有配套的精品资源点击获取