Startup类和服务配置
在 Startup 类中,有两个方法:ConfigureServices 是用于服务注册,Configure 方法是向应用程序的请求管道中添加中间件。
因此,最好的方式是保持 ConfigureServices 方法简洁,并且尽可能地具有可读性。当然,我们需要在该方法内部编写代码来注册服务,但是我们可以通过使用 扩展方法 来让我们的代码更加地可读和可维护。
尽管这种方式看起来挺好,也能正常地将 CORS 服务注册成功。但是想象一下,在注册了十几个服务之后这个方法体的长度。这样一点也不具有可读性。一种好的方式是通过在扩展类中创建静态方法:
public static class ServiceExtensions {
public static void ConfigureCors(this IServiceCollection services) {
services.AddCors(options =>
{
options.AddPolicy("CorsPolicy", builder => builder.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials());
});
}
}
在一些不同的示例教程中,我们可能看到 DAL 的实现在主项目中,并且每个控制器中都有实例。我们不建议这么做。当我们编写 DAL 时,我们应该将其作为一个独立的服务来创建。在 .NET Core 项目中,这一点很重要,因为当我们将 DAL 作为一个独立的服务时,我们就可以将其直接注入到 IOC(控制反转)容器中。IOC 是 .NET Core 内置功能。通过这种方式,我们可以在任何控制器中通过构造函数注入的方式来使用。
public class OwnerController: Controller
{
private readonly IRepository _repository;
public OwnerController(IRepository repository) {
_repository = repository;
}
}
控制器
控制器应该始终尽量保持整洁。我们不应该将任何业务逻辑放置于内。
因此,我们的控制器应该通过构造函数注入的方式接收服务实例,并组织 HTTP 的操作方法GET、POST、PUT、DELETE、PATCH...
public class OwnerController : Controller
{
private readonly ILoggerManager _logger;
private readonly IRepository _repository;
public OwnerController(ILoggerManager logger, IRepository repository) {
_logger = logger;
_repository = repository;
}
[HttpGet]
public IActionResult GetAllOwners() {
}
[HttpGet("{id}", Name = "OwnerById")]
public IActionResult GetOwnerById(Guid id) {
}
[HttpGet("{id}/account")]
public IActionResult GetOwnerWithDetails(Guid id) {
}
[HttpPost]
public IActionResult CreateOwner([FromBody]Owner owner) {
}
[HttpPut("{id}")]
public IActionResult UpdateOwner(Guid id, [FromBody]Owner owner) {
}
[HttpDelete("{id}")]
public IActionResult DeleteOwner(Guid id) {
}
}
我们的 Action 应该尽量保持简洁,它们的职责应该包括处理 HTTP 请求,验证模型,捕捉异常和返回响应。
[HttpPost]
public IActionResult CreateOwner([FromBody]Owner owner) {
try
{
if (owner.IsObjectNull())
{
return BadRequest("Owner object is null");
}
if (!ModelState.IsValid)
{
return BadRequest("Invalid model object");
}
_repository.Owner.CreateOwner(owner);
return CreatedAtRoute("OwnerById", new { id = owner.Id }, owner);
}
catch (Exception ex)
{
_logger.LogError($"Something went wrong inside the CreateOwner action: { ex} ");
return StatusCode(500, "Internal server error");
}
}
在大多数情况下,我们的 action 应该将 IActonResult 作为返回类型(有时我们希望返回一个特定类型或者是 JsonResult ...)。通过使用这种方式,我们可以很好地使用 .NET Core 中内置方法的返回值和状态码。
使用最多的方法是:
OK => returns the 200 status code
NotFound => returns the 404 status code
BadRequest => returns the 400 status code
NoContent => returns the 204 status code
Created, CreatedAtRoute, CreatedAtAction => returns the 201 status code
Unauthorized => returns the 401 status code
Forbid => returns the 403 status code
StatusCode => returns the status code we provide as input
处理全局异常
在上面的示例中,我们的 action 内部有一个 try-catch 代码块。这一点很重要,我们需要在我们的 action 方法体中处理所有的异常(包括未处理的)。一些开发者在 action 中使用 try-catch 代码块,这种方式明显没有任何问题。但我们希望 action 尽量保持简洁。因此,从我们的 action 中删除 try-catch ,并将其放在一个集中的地方会是一种更好的方式。.NET Core 给我们提供了一种处理全局异常的方式,只需要稍加修改,就可以使用内置且完善的的中间件。我们需要做的修改就是在 Startup 类中修改 Configure 方法。
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseExceptionHandler(config =>
{
config.Run(async context =>
{
context.Response.StatusCode = 500;
context.Response.ContentType = "application/json";
var error = context.Features.Get<IExceptionHandlerFeature>();
if (error != null)
{
var ex = error.Error;
await context.Response.WriteAsync(new ErrorModel
{
StatusCode = 500,
ErrorMessage = ex.Message
}.ToString());
}
});
});
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
我们也可以通过创建自定义的中间件来实现我们的自定义异常处理:
// You may need to install the Microsoft.AspNetCore.Http.Abstractions package into your project
public class CustomExceptionMiddleware
{
private readonly RequestDelegate _next;
private readonly ILogger<CustomExceptionMiddleware> _logger;
public CustomExceptionMiddleware(RequestDelegate next, ILogger<CustomExceptionMiddleware> logger) {
_next = next;
_logger = logger;
}
public async Task Invoke(HttpContext httpContext) {
try
{
await _next(httpContext);
}
catch (Exception ex)
{
_logger.LogError("Unhandled exception....", ex);
await HandleExceptionAsync(httpContext, ex);
}
}
private Task HandleExceptionAsync(HttpContext httpContext, Exception ex) {
//todo
return Task.CompletedTask;
}
}
// Extension method used to add the middleware to the HTTP request pipeline.
public static class CustomExceptionMiddlewareExtensions
{
public static IApplicationBuilder UseCustomExceptionMiddleware(this IApplicationBuilder builder) {
return builder.UseMiddleware<CustomExceptionMiddleware>();
}
}
之后,我们只需要将其注入到应用程序的请求管道中即可:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
app.UseCustomExceptionMiddleware();
}
使用过滤器移除重复代码
http://ASP.NET Core 的过滤器可以让我们在请求管道的特定状态之前或之后运行一些代码。因此如果我们的 action 中有重复验证的话,可以使用它来简化验证操作。
当我们在 action 方法中处理 PUT 或者 POST 请求时,我们需要验证我们的模型对象是否符合我们的预期。作为结果,这将导致我们的验证代码重复,我们希望避免出现这种情况,(基本上,我们应该尽我们所能避免出现任何代码重复。)我们可以在代码中通过使用 ActionFilter 来代替我们的验证代码:
if (!ModelState.IsValid)
{
//bad request and logging logic
}
我们可以创建一个过滤器:
public class ModelValidationAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext context) {
if (!context.ModelState.IsValid)
{
context.Result = new BadRequestObjectResult(context.ModelState);
}
}
}
然后在 Startup 类的 ConfigureServices 函数中将其注入:
services.AddScoped<ModelValidationAttribute>();
现在,我们可以将上述注入的过滤器应用到我们的 action 中。