掌握API建模：基本概念和实践
.NET Core Web APi类库如何内嵌运行和.NET Core Web API 中的异常处理
2024-12-02
内嵌运行.NET Core Web APi
接下来我们通过控制台作为主程序来启动Web APi，首先我们创建名为EmbedWebApi的控制台程序，然后创建Embed.WebApi类库运行Web APi，我们在此Web APi中创建如下接口，并实现相关方法来运行Web APi。
public class InitTest : IInitTest
{
public void Init()
{
var builder = WebApplication.CreateBuilder();
builder.Services.AddControllers();
var app = builder.Build();
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapDefaultControllerRoute();
});
app.Run();
}
}
public interface IInitTest
{
void Init();
}通过写接口并在对应方法中运行Web APi主要是达到在控制中调用该接口进行模拟实现，这里需要注意一点的是，因为我们创建的Web APi是类库，要想使用Web里面的Api等等，直接在项目文件中添加如下一行以表明我们要引用框架，这样一来框架里面所包含的APi等等版本都一致统一，而不是通过NuGet一一下载，这是错误的做法。
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>接下来我们在该类库中按照规范创建Controllers文件夹，并创建测试控制器，如下
using Microsoft.AspNetCore.Mvc;
namespace Embed.WebApi.Controllers
{
[ApiController]
[Route("api/[controller]/[action]")]
public class TestController : ControllerBase
{
[HttpGet]
public IActionResult Test()
{
return Ok("Hello World");
}
}
}最后我们在控制台程序中注册上述接口并调用初始化方法，如下：
internal class Program
{
static void Main(string[] args)
{
var services = new ServiceCollection();
services.AddTransient<IInitTest, InitTest>();
var serviceProvider = services.BuildServiceProvider();
var initTest = serviceProvider.GetRequiredService<IInitTest>();
initTest.Init();
Console.Read();
}
}
芜湖，我们通过Postman模拟调用测试接口，结果惊呆了，404了~~~
当我们将类库中的控制器移动到控制台中，此时请求测试接口并成功返回对世界的问候，这是什么原因呢？不难猜测可知，WebAPi控制器的激活以作为入口的主程序集进行查找激活。
虽然这样看似解决了问题，假设调用嵌入运行的主程序是底层已经封装好的基础设施，那么岂不是遭到了代码入侵，所以我们就想在运行的Web APi类库里面去激活，此时我们想到将类库作为Web APi应用程序一部分应用手动加载并激活，在初始化方法里面修改为如下即可请求测试接口成功
public class InitTest : IInitTest
{
private static readonly string AssemblyName = typeof(InitTest).Assembly.GetName().Name;
public void Init()
{
var builder = WebApplication.CreateBuilder();
builder.Services.AddControllers()
.AddApplicationPart(Assembly.Load(new AssemblyName(AssemblyName)));
var app = builder.Build();
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapDefaultControllerRoute();
});
app.Run();
}
}上述直接在运行Web APi类库中添加控制器激活，这种场景完全限定于底层主入口已封装好，所以只能采用这种方式，若是主入口我们自己可控制，当然还有另外一种方式，来，我们瞧瞧截取的关键性源码
/// <summary>
/// Populates the given <paramref name="feature"/> using the list of
/// <see cref="IApplicationFeatureProvider{TFeature}"/>s configured on the
/// <see cref="ApplicationPartManager"/>.
/// </summary>
/// <typeparam name="TFeature">The type of the feature.</typeparam>
/// <param name="feature">The feature instance to populate.</param>
public void PopulateFeature<TFeature>(TFeature feature)
{
if (feature == null)
{
throw new ArgumentNullException(nameof(feature));
}
foreach (var provider in FeatureProviders.OfType<IApplicationFeatureProvider<TFeature>>())
{
provider.PopulateFeature(ApplicationParts, feature);
}
}
internal void PopulateDefaultParts(string entryAssemblyName)
{
var assemblies = GetApplicationPartAssemblies(entryAssemblyName);
var seenAssemblies = new HashSet<Assembly>();
foreach (var assembly in assemblies)
{
if (!seenAssemblies.Add(assembly))
{
// "assemblies" may contain duplicate values, but we want unique ApplicationPart instances.
// Note that we prefer using a HashSet over Distinct since the latter isn't
// guaranteed to preserve the original ordering.
continue;
}
var partFactory = ApplicationPartFactory.GetApplicationPartFactory(assembly);
foreach (var applicationPart in partFactory.GetApplicationParts(assembly))
{
ApplicationParts.Add(applicationPart);
}
}
}
private static IEnumerable<Assembly> GetApplicationPartAssemblies(string entryAssemblyName)
{
var entryAssembly = Assembly.Load(new AssemblyName(entryAssemblyName));
// Use ApplicationPartAttribute to get the closure of direct or transitive dependencies
// that reference MVC.
var assembliesFromAttributes = entryAssembly.GetCustomAttributes<ApplicationPartAttribute>()
.Select(name => Assembly.Load(name.AssemblyName))
.OrderBy(assembly => assembly.FullName, StringComparer.Ordinal)
.SelectMany(GetAssemblyClosure);
// The SDK will not include the entry assembly as an application part. We'll explicitly list it
// and have it appear before all other assemblies \ ApplicationParts.
return GetAssemblyClosure(entryAssembly)
.Concat(assembliesFromAttributes);
}
private static IEnumerable<Assembly> GetAssemblyClosure(Assembly assembly)
{
yield return assembly;
var relatedAssemblies = RelatedAssemblyAttribute.GetRelatedAssemblies(assembly, throwOnError: false)
.OrderBy(assembly => assembly.FullName, StringComparer.Ordinal);
foreach (var relatedAssembly in relatedAssemblies)
{
yield return relatedAssembly;
}
}从上述源码可知，通过主入口程序集还会加载引用的程序集去查找并激活相关特性（比如控制器），当然前提是实现ApplicationPartAttribute特性，此特性必须在主入口程序集里定义，定义在程序集上
所以我们只需一行代码即可搞定，我们在控制台主入口命名空间顶部添加特性，引入Web APi类库程序集作为应用程序的一部分，如下：
[assembly: ApplicationPart("Embed.WebApi")]
那么接下来问题又来了，要是需要运行多个Web APi我们又当如何呢？按照上述方式一一添加未尝不可，我们也可以通过MSBuild任务来进行构建将相关特性自动添加到主入口程序集描述信息里面去，例如：
<ItemGroup>
<AssemblyAttribute Include="Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartAttribute">
<_Parameter1>Embed.WebApi</_Parameter1>
</AssemblyAttribute>
</ItemGroup>有的童鞋就问了，这不写死了么，那还不如通过添加特性的方式去处理，请注意这里只是使用示例
实际情况下，我们可将多个Web APi放在同一解决方案下，然后在此解决方案下创建可构建任务的.targets文件，并在主项目文件里引入，将程序集名称作为变量引入，剩下事情自行统一处理，若不清楚怎么搞，就在代码中使用特性方式也未尝不可，例如如下：
<ItemGroup>
<AssemblyAttribute Include="Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartAttribute">
<_Parameter1>$(AssemblyName)</_Parameter1>
</AssemblyAttribute>
</ItemGroup>
概述：有效处理异常对于构建健壮且用户友好的应用程序至关重要。本文深入探讨 .NET Core Web API 中的异常处理，演示如何创建自定义异常并全局管理它们，以实现更简洁、更高效的代码库。为什么异常处理很重要正确处理的异常可确保应用程序在所有情况下的行为都具有可预测性。它可以防止向最终用户公开敏感的错误详细信息。它为用户提供有意义的反馈，增强他们的体验。它使代码库更易于维护和调试。构建自定义异常自定义异常允许您更清楚地表达特定的错误条件。让我们为核心 Web API 创建四个自定义异常。NotFoundException当找不到请求的资源时，将引发此异常。public class NotFoun
有效处理异常对于构建健壮且用户友好的应用程序至关重要。本文深入探讨 .NET Core Web API 中的异常处理，演示如何创建自定义异常并全局管理它们，以实现更简洁、更高效的代码库。
为什么异常处理很重要
- 正确处理的异常可确保应用程序在所有情况下的行为都具有可预测性。
- 它可以防止向最终用户公开敏感的错误详细信息。
- 它为用户提供有意义的反馈，增强他们的体验。
- 它使代码库更易于维护和调试。
构建自定义异常
自定义异常允许您更清楚地表达特定的错误条件。让我们为核心 Web API 创建四个自定义异常。
NotFoundException
当找不到请求的资源时，将引发此异常。
public class NotFoundException : Exception
{
public NotFoundException(string message) : base(message) { }
}ValidationException
当数据验证失败时，请使用此选项。
public class ValidationException : Exception
{
public ValidationException(string message) : base(message) { }
}UnauthorizedAccessException
指示对资源的未经授权的访问。
public class UnauthorizedAccessException : Exception
{
public UnauthorizedAccessException(string message) : base(message) { }
}InternalServerErrorException
表示应用程序中的意外故障。
public class InternalServerErrorException : Exception
{
public InternalServerErrorException(string message) : base(message) { }
}全局异常处理
.NET Core 允许全局处理异常，而不是将 try-catch 块分散在整个代码中。这是使用中间件或过滤器完成的。我们将重点介绍如何使用全局筛选器。
public class GlobalExceptionFilter : IExceptionFilter
{
public void OnException(ExceptionContext context)
{
var statusCode = context.Exception switch
{
NotFoundException => StatusCodes.Status404NotFound,
ValidationException => StatusCodes.Status400BadRequest,
UnauthorizedAccessException => StatusCodes.Status401Unauthorized,
_ => StatusCodes.Status500InternalServerError
};
context.Result = new ObjectResult(new
{
error = context.Exception.Message,
stackTrace = context.Exception.StackTrace
})
{
StatusCode = statusCode
};
}
}此筛选器将截获异常并将其转换为适当的 HTTP 响应。
注册全局筛选器
在 中，注册全局筛选器。Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers(options =>
{
options.Filters.Add(new GlobalExceptionFilter());
});
}
引发自定义异常，由 .Net Core Web API 中的全局筛选器捕获 – 图片来源：由作者创建
自定义异常的用法
为了演示 .NET Core Web API 中自定义异常和全局异常筛选器的用法，让我们创建一个简单的示例。这将涉及一个引发这些异常的控制器，演示全局异常筛选器如何捕获和处理这些异常。
[ApiController]
[Route("[controller]")]
public class SampleController : ControllerBase
{
[HttpGet("not-found")]
public ActionResult GetNotFound()
{
// Simulate a situation where a resource is not found
throw new NotFoundException("The requested resource was not found.");
}
[HttpGet("invalid")]
public ActionResult GetInvalid()
{
// Simulate a validation error
throw new ValidationException("Validation failed for the request.");
}
[HttpGet("unauthorized")]
public ActionResult GetUnauthorized()
{
// Simulate unauthorized access
throw new UnauthorizedAccessException("You do not have permission to access this resource.");
}
[HttpGet("internal-error")]
public ActionResult GetInternalError()
{
// Simulate an internal server error
throw new InternalServerErrorException("An unexpected error occurred.");
}
}运行 Web API 并向这些终结点发出请求时，将引发相应的自定义异常。
A GET request to /sample/not-found will throw the NotFoundException.
A GET request to /sample/invalid will throw the ValidationException.
当引发这些异常时，全局异常筛选器会捕获它们。然后，它将每个异常映射到相应的 HTTP 状态代码，并向客户端返回结构化响应。
例如，如果引发，筛选器将返回 404 Not Found 状态，其中包含包含错误消息和堆栈跟踪的 JSON 正文。NotFoundException
对全局异常筛选器进行单元测试
测试全局异常筛选器包括检查它是否正确地将异常转换为相应的 HTTP 响应。
若要对此进行测试，可以模拟引发异常的操作方法，然后断言筛选器的响应。使用 Moq 和 xUnit 的示例测试。
public class GlobalExceptionFilterTests
{
[Fact]
public void OnException_ShouldSetCorrectStatusCodeForNotFoundException()
{
// Arrange
var exceptionContextMock = new Mock<ExceptionContext>();
exceptionContextMock.SetupGet(x => x.Exception).Returns(new NotFoundException("Not found"));
var filter = new GlobalExceptionFilter();
// Act
filter.OnException(exceptionContextMock.Object);
// Assert
var objectResult = exceptionContextMock.Object.Result as ObjectResult;
Assert.NotNull(objectResult);
Assert.Equal(StatusCodes.Status404NotFound, objectResult.StatusCode);
}
}本文章转载微信公众号@JeffckyShare
同话题下的热门内容
