掌握API建模：基本概念和實踐
通過寫接口并在對應方法中運行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
