项目，从webform升级到.net8的过程

需求：

为了适应跨平台的问题，和项目开发的技术更迭，考虑把原来的webform升级为最新的webapi方式；

技术分析：

原项目用的extjs+webform的构建方式，经典5层（DALFactory、DLL、IDAL、SQLServerDAL、Web）。
extjs可以说早一点前后端分离的典范了。全站只有js代码，连基本的html页都不存在。在当年也是顶流的设计思路了，无疑是走在了历史的前沿了。奈何被现在的前端ui框架爆的基本上没有发展空间了。

好消息是这种前后端分离的方式，升级只用完成aspx页面的完美蜕变即可。
aspx页的处理逻辑是，Page_Load入口，然后根据verb参数统一判断处理逻辑，统计返回json格式数据。

实施方案：

于是就有了基本的思路了，直接aspx.cs类，继承ControllerBase，完成webapi的华丽升级；
然后面临着重点改造了，就是从aspx适配器webapi，统一用扩张类AspxExt；

• 一些有前端aspx页代码的，用同等的RazorPages置换；（好在没几个）

• web.config（配置保留，尽量不动源程序的任何代码）

• 其他aspx类似api性质的页面统一处理
  使用了.net的部分类partial功能，统一给类增加了webapi的特性路由标识，统一public的Do方法作为webapi的入口。
  

• Response.Write，Response.End
  

• Request.Form\Query
  

• File.SaveAs
  

• Server
  

• Global.asax
  
  

• 静态资源都加wwwroot

• 数据访问层，基本原sql的不用动，微软企业库有平替版本。

到这里几基本上项目就没啥大问题了，剩下就是零散的调试和修改了。

---

总结

1、前后端分离。
如果全是webform+的方式，只能一个个修改了。后期升级没法批量操作了，或者没遇到也没有分析这个解决方案。
从另一方面说明了微软曾经要一统计页面的方案是不科学的，从webform错失ajax，到现在的razor\blazor还是这个思路,用c#取代js+。无论从项目的开发分工，还是后期的升级讲，思路都是不对的。
前端去干前端，后端去干后端才是科学的选择。

2、技术的升级必然带来兼容问题。
向后兼容一直是软件设计的一个硬伤。如果不能完美兼容必然带来升级的费力，如果兼容就又对软件有掣肘的问题。python2、python3不也是这样。

从.netframework2.0,一路走来.netframework4.8，再到现在的.net9。微软一直在努力，但是结果呢，市场一点点丢失，人员也折腾的凋零。微软好像一直没跟上。
因为跨平台问题，微软完美了错过了移动互联网。java成了android的宠儿，一飞冲天，为了能分杯羹，xamarin到现在maui。多端时代webapi是必然选择，ai时代又有什么期待？
一路走来好像总是滞后，一步错步步错？总是事后找补，真的是难！！！
c#从2000年出生到现在25年了，还能有多少期待？