freeCodeCamp.org

如何从ASP.NET Framework迁移到ASP.NET Core

6.5内容质量
如何从ASP.NET Framework迁移到ASP.NET Core

TL;DR · AI 摘要

本文提供从ASP.NET Framework迁移到ASP.NET Core的实用指南,涵盖架构差异、迁移策略选择和实施建议,推荐采用增量迁移模式降低风险,强调API优先迁移和全面测试的重要性。

核心要点

  • 推荐采用Strangler Fig模式的增量迁移策略,而非一次性重写,可显著降低大型项目的迁移风险
  • 迁移前需重点评估API兼容性、第三方依赖支持和认证机制重构等核心挑战
  • 迁移应遵循"先API后UI"的顺序,配合并行运行和全面测试确保平滑过渡

结构提纲

按章节快速跳转。

  1. ASP.NET Core作为轻量级、模块化的高性能框架,支持跨平台部署和云原生扩展,是现代化遗留应用的理想选择。

  2. 迁移前需掌握MVC架构、C#和.NET开发基础,熟悉依赖注入、REST API和Entity Framework,并准备.NET 6+ SDK和版本控制系统。

  3. 从System.Web紧耦合架构转向模块化中间件管道,原生支持依赖注入,采用JSON配置系统替代XML的web.config。

  4. 主要挑战包括代码紧耦合、API不兼容、第三方库不支持、认证机制差异以及大型单体应用的分解复杂性。

  5. 增量迁移(推荐)通过Strangler Fig模式逐步替换组件,风险更低;大爆炸迁移适合小型应用但风险较高。

  6. 建议从小规模试点开始,优先迁移API,逐步转换UI组件,并行运行验证,建立完整的测试策略确保迁移可靠性。

金句 / Highlights

值得收藏与分享的关键句。

  • 迁移到ASP.NET Core是一项战略性升级,可提升性能、可扩展性和跨平台支持能力。

    引言

    ⬇︎ 下载 PNG𝕏 分享到 X
  • 与其进行高风险的一次性重写,不如采用增量迁移、重构依赖注入并优先测试。

    引言

    ⬇︎ 下载 PNG𝕏 分享到 X
  • Strangler Fig模式命名源于一种绕着宿主树生长并逐渐取代它的藤蔓植物。

    迁移策略

    ⬇︎ 下载 PNG𝕏 分享到 X
  • 从小规模开始,优先迁移API,逐步转换UI组件,确保现代化过程平滑可靠。

    引言

    ⬇︎ 下载 PNG𝕏 分享到 X
#ASP.NET Core#.NET#迁移策略#微服务#架构重构
打开原文
图片 1:如何从 ASP.NET Framework 迁移到 ASP.NET Core
图片 1:如何从 ASP.NET Framework 迁移到 ASP.NET Core

迁移到 ASP.NET Core 是一项战略性升级,可以提升性能、可扩展性和跨平台支持。您无需冒险进行完全重写,可以采用增量方法、重构以实现依赖注入,并优先进行测试。从小处着手,先迁移 API,然后逐步过渡 UI 组件,以确保现代化过程平稳可靠。

在本文中,您将学习如何通过从 ASP.NET Framework 迁移到 ASP.NET Core 来实现遗留应用的现代化。本指南涵盖架构差异、迁移策略、分步实施以及构建可扩展、高性能 Web 应用程序的最佳实践。

**目录**

基于 ASP.NET Framework 构建的遗留系统为企业应用提供了十余年的支持。虽然稳定且成熟,但这些系统往往难以满足现代需求,例如跨平台部署、云原生可扩展性和高性能工作负载。随着业务发展,这些应用的现代化需求变得不可避免。

这就是 ASP.NET Core 的用武之地。ASP.NET Core 作为一个轻量级、模块化的高性能框架,使开发者能够构建可在 Windows、Linux 和 macOS 上运行的可扩展应用。

在本文中,我们将探讨将遗留 ASP.NET Framework 应用迁移到 ASP.NET Core MVC 的实用技术方法。与专注于理论不同,我们将重点放在架构差异、迁移策略和分步执行上。

**前置条件**

在迁移到 ASP.NET Core 之前,开发者应该对 MVC 架构、C# 和基本的 .NET 开发概念有扎实的理解。熟悉依赖注入、REST API 和 Entity Framework 将使迁移过程更加轻松。

您还应该具备:

  • 已安装 .NET SDK(推荐 .NET 6 或更高版本)
  • 基本的 CLI 命令知识
  • NuGet 包管理经验
  • 了解 IIS 或 Web 托管环境
  • Git 等版本控制系统

对于企业项目,在开始迁移之前,建议访问预发布环境和自动化测试管道。

**理解架构转变**

迁移到 ASP.NET Core 不仅仅是版本升级——这是一次根本性的架构转变

**从单体到模块化**

ASP.NET 严重依赖 System.Web 程序集,它将 HTTP 处理、会话状态和缓存等组件紧密耦合。相比之下,ASP.NET Core 移除了这个依赖,引入了模块化的中间件管道。

**内置依赖注入**

ASP.NET 中的依赖注入(DI)需要第三方库,如 Autofac 或 Ninject。ASP.NET Core 原生包含 DI,促进了更好的关注点分离。

**统一运行时**

ASP.NET Core 运行在现代 .NET 生态系统(例如 .NET 6+)上,统一了之前分散的运行时并提升了性能。

**配置重构**

配置已从基于 XML 的 web.config 文件迁移到灵活的基于 JSON 的系统,如 appsettings.json,支持环境特定配置。

**迁移中的主要挑战**

在深入了解流程之前,了解这些挑战很重要:

  • 紧耦合的代码库:遗留应用通常混合了业务逻辑、UI 和数据访问。
  • 不支持的 API:ASP.NET 中使用的一些 API 在 Core 中不可用。
  • 第三方依赖:较旧的库可能不支持 .NET Core。
  • 身份验证差异:表单身份验证和旧版身份系统需要重构。
  • 大型单体:拆分大型应用非常耗时。

忽略这些挑战往往会导致迁移失败或不完整。

**迁移策略**

选择正确的迁移方法至关重要。

**大爆炸迁移**

这种方法涉及一次性重写整个应用。

优点:

  • 架构干净
  • 没有遗留负担

缺点:

  • 高风险
  • 时间线长
  • 需要完整的回归测试

这种方法通常不推荐用于大型系统。

**增量迁移(推荐)**

这里通常使用绞杀榕模式。新功能在 ASP.NET Core 中构建,同时逐步替换遗留组件。

绞杀榕模式以缠绕宿主树并随着时间推移逐渐取代它的藤蔓命名。在软件现代化中,这种模式涉及在现有应用旁边构建新功能,并在组件迁移时将特定请求路由到新系统。团队无需一次性替换整个应用,而是逐步"绞杀"遗留系统,直到新的 ASP.NET Core 应用完全接管。

好处:

  • 降低风险
  • 持续交付
  • 更容易调试

**混合方法**

并排运行 ASP.NET Framework 和 ASP.NET Core。某些模块(例如 API)可以先迁移,而 UI 保持不变。

优点:

  • 迁移风险更低
  • 干扰最小
  • 支持分阶段推出

缺点:

  • 运营复杂性增加
  • 额外的部署开销
  • 临时架构重复

这种方法对于大型企业系统特别有用,在这些系统中,维护业务连续性比快速完成迁移更重要。

**迁移前评估**

成功的迁移始于适当的规划。

**步骤 1:升级现有应用程序**

确保您的应用程序运行在最新版本的 ASP.NET Framework 上。这可以最大程度减少兼容性问题。

**步骤 2:创建新的 ASP.NET Core MVC 项目**

使用 CLI:

code
dotnet new mvc -n ModernApp

这将创建一个具有现代结构的干净项目:

  • Program.cs(入口点)
  • Controllers/
  • Views/
  • wwwroot/

**步骤 3:迁移配置**

web.config 替换为 appsettings.json

旧版本(`web.config`):

code
<appSettings>
  <add key="ApiUrl" value="https://api.example.com" />
</appSettings>

新版本(`appsettings.json`):

code
{
  "ApiSettings": {
    "BaseUrl": "https://api.example.com"
  }
}

在代码中访问:

code
public class HomeController : Controller
{
    private readonly IConfiguration _config;

    public HomeController(IConfiguration config)
    {
        _config = config;
    }

    public IActionResult Index()
    {
        var url = _config["ApiSettings:BaseUrl"];
        return View();
    }
}

**步骤 4:用 Middleware 替换 Global.asax**

ASP.NET Core 使用中间件管道而不是生命周期事件。

code
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseRouting();
app.UseAuthorization();

app.MapControllers();

app.Run();

与旧的事件驱动模型相比,这个管道提供了更多的控制和灵活性。

**步骤 5:迁移控制器和视图**

控制器逻辑类似,但返回类型发生了变化。

ASP.NET Framework:

code
public ActionResult Index()
{
    return View();
}

ASP.NET Core:

code
public IActionResult Index()
{
    return View();
}

视图(Razor)需要小幅更新,特别是标签助手(tag helpers)。

**步骤 6:实现依赖注入**

用 DI 替换紧耦合的服务。

code
public interface IProductService
{
    List<string> GetProducts();
}

public class ProductService : IProductService
{
    public List<string> GetProducts()
    {
        return new List<string> { "Laptop", "Phone" };
    }
}

注册服务:

code
builder.Services.AddScoped<IProductService, ProductService>();

在控制器中使用:

code
public class ProductController : Controller
{
    private readonly IProductService _service;

    public ProductController(IProductService service)
    {
        _service = service;
    }

    public IActionResult Index()
    {
        var products = _service.GetProducts();
        return View(products);
    }
}

**步骤 7:迁移数据访问层**

大多数遗留应用程序使用 Entity Framework。在 ASP.NET Core 中,您将使用 Entity Framework Core。

DbContext 示例:

code
public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options) { }
}

Program.cs 中注册:

code
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer("YourConnectionString"));

**步骤 8:身份验证和授权**

ASP.NET Core 提供了灵活的身份验证机制:

  • 基于 Cookie 的身份验证
  • JWT 令牌
  • OAuth 提供程序

示例:

code
builder.Services.AddAuthentication("CookieAuth")
    .AddCookie("CookieAuth", config =>
    {
        config.LoginPath = "/Account/Login";
    });

**步骤 9:测试和验证**

测试在迁移过程中变得至关重要:

  • 单元测试(xUnitNUnit
  • 集成测试
  • 回归测试

确保新旧系统之间的功能 parity(功能对等)。

例如,在将遗留的 ASP.NET Framework API 迁移到 ASP.NET Core 之后,您可以使用集成测试来验证行为,确保响应与原始系统匹配。

示例:集成测试(xUnit)

code
[Fact]
public async Task GetProducts_ShouldReturnSuccessStatus()
{
    // Arrange
    var client = _factory.CreateClient();

    // Act
    var response = await client.GetAsync("/api/products");

    // Assert
    response.EnsureSuccessStatusCode();
}

在过渡期间,您还可以并排比较遗留和迁移后的端点:

  • /legacy/api/products → ASP.NET Framework
  • /api/products → ASP.NET Core

然后并行运行请求并验证响应在结构、状态码和数据完整性方面的一致性。这有助于确保在完全停用遗留系统之前,迁移不会引入行为回归。

**性能和可扩展性提升**

ASP.NET Core 带来了显著的改进:

  • Kestrel Web Server:高性能、跨平台服务器
  • 异步优先设计:高效的请求处理
  • 更低的内存占用
  • 负载下更好的吞吐量

这些改进使其非常适合微服务和云部署。

**部署现代化**

传统上,遗留应用程序与 IIS 托管环境紧密耦合,这限制了部署和扩展的灵活性。使用 ASP.NET Core,现在可以使用现代、可移植和自动化的基础设施方法来部署应用程序,更好地支持云原生开发和持续交付。

**容器化**

容器化允许将应用程序及其所有依赖项打包成一个独立的、可移植的单元,可以在不同环境中一致地运行。使用 Docker 等工具,ASP.NET Core 应用程序可以在开发、暂存和生产环境中可靠地部署,而无需处理特定环境的配置问题。这种方法还简化了分布式系统中的扩展和回滚策略。

code
FROM mcr.microsoft.com/dotnet/aspnet:6.0
COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "ModernApp.dll"]

**CI/CD 集成**

持续集成和持续部署(CI/CD)管道自动化了应用程序的构建、测试和部署过程。在迁移场景中,CI/CD 变得尤为重要,因为它确保了传统组件和现代化组件在增量发布过程中保持稳定。GitHub Actions 和 Azure DevOps 等平台帮助团队快速验证变更,并在从 ASP.NET Framework 迁移到 ASP.NET Core 时降低回归风险。

使用 CI/CD 还可以实现:

  • 分阶段迁移期间更快的发布周期
  • 迁移模块的自动化测试
  • 部署失败时的安全回滚

这确保了自动化构建、测试和部署。

**常见陷阱**

**低估复杂性**

迁移不仅仅是代码转换——它涉及重新思考整个架构。中间件、配置和托管模型的差异意味着团队必须重新设计关键组件,而不是简单地移植它们。

**忽视依赖项**

许多传统应用程序依赖的第三方库可能不支持 ASP.NET Core。未能及早评估兼容性可能会导致障碍,迫使团队在最后一刻进行重写或替换。

**跳过增量方法**

尝试完整的"大爆炸"式迁移会增加风险,往往导致延迟或失败。增量策略允许团队逐步验证变更,并在整个过渡过程中维护系统稳定性。

**测试不足**

测试不足可能会将关键缺陷引入生产系统。全面的单元测试、集成测试和回归测试对于确保新应用程序的行为与旧系统一致至关重要。

**实际用例**

**企业 ERP 系统现代化**

建立在 ASP.NET 上的大型 ERP 系统由于架构紧密耦合,往往难以扩展和维护。将这些系统迁移到 ASP.NET Core 使组织能够模块化组件、提高性能并支持云部署。这种过渡还使得引入微服务和现代 DevOps 实践变得更加容易。

**电子商务平台扩展**

电子商务应用需要高可用性和处理流量高峰的能力。通过迁移到 ASP.NET Core,企业可以利用异步处理改进、改进的请求处理和基于容器的扩展。这确保了更快的页面加载、更好的用户体验以及高效处理峰值需求的能力。

**API 优先的后端转型**

现代应用越来越多地采用 API 优先方法,后端作为一组独立服务设计。ASP.NET Core 简化了 RESTful API 的构建,具有更好的路由、序列化和性能。组织通常首先迁移 API 以建立可扩展的后端,然后逐步过渡 UI 层以与新架构对齐。

**最佳实践清单**

**从小型模块开始**

不要一次性迁移整个应用程序,而是从低风险的模块开始,例如报表功能或内部 API。这有助于团队了解迁移过程,及早发现挑战,并在将工作扩展到整个系统之前建立信心。

**使用增量迁移**

增量方法(如绞杀榕树模式)允许传统系统和现代系统在过渡期间共存。这减少了停机时间、最大限度地降低了风险,并确保在逐步用 ASP.NET Core 服务替换传统组件时持续交付。

**尽早重构依赖注入**

依赖注入是 ASP.NET Core 的核心原则,尽早采用它可以简化未来开发。将紧密耦合的组件重构为松耦合的服务可以提高可测试性、可维护性以及迁移期间和之后的整体代码质量。

**持续监控性能**

应使用日志和监控工具在迁移过程中跟踪性能。比较旧系统与新实现之间的指标有助于验证改进,并确保快速发现和解决性能回归问题。

**保持向后兼容**

在迁移期间,确保现有客户端和集成继续正常运行至关重要。通过版本化 API 或适配器保持向后兼容可以实现平滑过渡,而不会中断用户或依赖系统。

**何时不应该迁移**

迁移并不总是正确的决策。如果传统应用程序稳定、很少更新且满足业务需求,完整的迁移可能不值得付出成本和工程努力。一些企业系统还严重依赖没有 ASP.NET Core 等效项的 Windows 特定技术或第三方库。

在以下情况下应避免立即迁移:

  • 业务风险超过现代化收益
  • 应用程序即将停用
  • 关键依赖项在 .NET Core 中不受支持
  • 团队缺乏测试和重构的资源
  • 停机或不稳定可能严重影响运营

在这些情况下,维护现有系统同时逐步现代化特定模块可能是更实用的策略。

**未来增强**

随着组织继续使用 ASP.NET Core 对应用程序进行现代化改造,未来的增强通常会关注可扩展性、自动化和云原生开发实践。迁移到 ASP.NET Core 为采用更新的架构模式和基础设施技术奠定了基础。

**微服务采用**

迁移后,许多组织逐渐将大型单体系统拆分为微服务。这提高了可扩展性、故障隔离和应用组件的独立部署能力,同时加快了开发周期。

**云原生部署**

ASP.NET Core 应用非常适合部署在 Microsoft Azure、Amazon Web Services (AWS) 和 Google Cloud 等云平台上。未来的增强可能包括自动扩展、无服务器工作负载和托管容器编排。

**使用 Kubernetes 进行容器编排**

容器化的 ASP.NET Core 应用可以使用 Kubernetes 进行管理,实现自动扩展、服务发现和高可用性。这对于企业级分布式系统特别有用。

**高级可观测性和监控**

现代系统越来越多地集成可观测性平台,如集中式日志、分布式追踪和性能监控。Prometheus 和 Grafana 等工具帮助团队主动发现问题并优化性能。

**API 网关和服务网格集成**

随着应用演变为分布式架构,API 网关和服务网格在流量管理、身份验证和安全性方面变得非常有价值。这增强了服务之间的通信,同时提高了弹性和治理能力。

**AI 辅助开发和自动化**

现代 .NET 生态系统越来越多地集成 AI 驱动的编码助手、自动化测试和智能 CI/CD 流水线。这些工具可以减少开发时间,提高代码质量,并简化迁移应用的长期维护。

**结论**

从 ASP.NET Framework 迁移到 ASP.NET Core MVC 是一项战略性的现代化努力,而不仅仅是技术升级。虽然这个过程涉及挑战——从架构变更到依赖问题——但长期收益是相当可观的。

通过采用渐进式方法、利用现代工具并专注于清晰的架构,组织可以成功过渡到一个专为性能、可扩展性和云原生开发而构建的平台。

ASP.NET Core 不仅是 .NET 的未来——它是当今分布式世界中构建弹性、现代应用的基础。

  • * *
  • * *

免费学习编程。freeCodeCamp 的开源课程已帮助超过 40,000 人获得了开发者工作机会。 开始学习