本文原文来源于CODE MAZE，译者Hippie Zhou，推荐者Edison Zhou。

介绍

当我们编写一个项目的时候，我们的主要目标是使它能如期运行，并尽可能地满足所有用户需求。

但是，你难道不认为创建一个能正常工作的项目还不够吗？同时这个项目不应该也是可维护和可读的吗？

事实证明，我们需要把更多的关注点放到我们项目的可读性和可维护性上。这背后的主要原因是我们或许不是这个项目的唯一编写者。一旦我们完成后，其他人也极有可能会加入到这里面来。

因此，我们应该把关注点放到哪里呢？

在这一份指南中，关于开发 .NET Core Web API 项目，我们将叙述一些我们认为会是最佳实践的方式。进而让我们的项目变得更好和更加具有可维护性。

现在，让我们开始想一些可以应用到 ASP.NET Web API 项目中的一些最佳实践。

StartUp类和服务配置

在 Startup 类中，有两个方法：ConfigureServices 是用于服务注册，Configure 方法是向应用程序的请求管道中添加中间件。

因此，最好的方式是保持 ConfigureServices 方法简洁，并且尽可能地具有可读性。当然，我们需要在该方法内部编写代码来注册服务，但是我们可以通过使用 扩展方法 来让我们的代码更加地可读和可维护。

例如，让我们看一个注册 CORS 服务的不好方式：

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options => 
    {
        options.AddPolicy("CorsPolicy", builder => builder.AllowAnyOrigin()
            .AllowAnyMethod()
            .AllowAnyHeader()
            .AllowCredentials());
    });
}

尽管这种方式看起来挺好，也能正常地将 CORS 服务注册成功。但是想象一下，在注册了十几个服务之后这个方法体的长度。

这样一点也不具有可读性。

一种好的方式是通过在扩展类中创建静态方法：

public static class ServiceExtensions
{
    public static void ConfigureCors(this IServiceCollection services)
    {
        services.AddCors(options =>
        {
            options.AddPolicy("CorsPolicy", builder => builder.AllowAnyOrigin()
                .AllowAnyMethod()
                .AllowAnyHeader()
                .AllowCredentials());
        });
    }
}

然后，只需要调用这个扩展方法即可：

public void ConfigureServices(IServiceCollection services)
{
    services.ConfigureCors();
}

了解更多关于 .NET Core 的项目配置，请查看：.NET Core Project Configuration

项目组织

我们应该尝试将我们的应用程序拆分为多个小项目。通过这种方式，我们可以获得最佳的项目组织方式，并能将关注点分离（SoC）。我们的实体、契约、访问数据库操作、记录信息或者发送邮件的业务逻辑应该始终放在单独的 .NET Core 类库项目中。

应用程序中的每个小项目都应该包含多个文件夹用来组织业务逻辑。

这里有个简单的示例用来展示一个复杂的项目应该如何组织

基于环境的配置

当我们开发应用程序时，它处于开发环境。但是一旦我们发布之后，它将处于生产环境。因此，将每个环境进行隔离配置往往是一种好的实践方式。

在 .NET Core 中，这一点很容易实现。

一旦我们创建好了项目，就已经有一个 appsettings.json 文件，当我们展开它时会看到 appsettings.Development.json 文件：

此文件中的所有设置将用于开发环境。

我们应该添加另一个文件 appsettings.Production.json，将其用于生产环境：

生产文件将位于开发文件下面。

设置修改后，我们就可以通过不同的 appsettings 文件来加载不同的配置，取决于我们应用程序当前所处环境，.NET Core 将会给我们提供正确的设置。更多关于这一主题，请查阅：Multiple Environments in ASP.NET Core.

数据访问层

在一些不同的示例教程中，我们可能看到 DAL 的实现在主项目中，并且每个控制器中都有实例。我们不建议这么做。

当我们编写 DAL 时，我们应该将其作为一个独立的服务来创建。在 .NET Core 项目中，这一点很重要，因为当我们将 DAL 作为一个独立的服务时，我们就可以将其直接注入到 IOC（控制反转）容器中。IOC 是 .NET Core 内置功能。通过这种方式，我们可以在任何控制器中通过构造函数注入的方式来使用。

public class OwnerController: Controller
{
    private readonly IRepository _repository;
    public OwnerController(IRepository repository)
    {
        _repository = repository;
    }
}

本系列其他部分

ASP.NET Core WebAPI 日常开发最佳实践（Part 2）

ASP.NET Core WebAPI 日常开发最佳实践（Part 3）

本文推荐者EdisonZhou，架构师，阿里云MVP，博客园"推荐博客"博主(Top10)，Scrum联盟认证CSM，.NET Core实践者与布道师，爱好阅读与分享。

本文首发于EdisonZhou的公众号“恰童鞋骚年”，欢迎关注，第一时间获得更多内容分享。

点击“了解更多”，直达推荐者博客。