关于.net:NET-6-Minimal-API-的经验分享

Minimal API 是 .NET 6 提供的最新性能，比照传统的 http://ASP.NET Core Web API 形式更加间接 , 你能够用几行代码编写好 REST API。没有了祖传的 Startup.cs 和 Controller，通过简略的代码就能够实现 API 的开发。在第二阶段的 .NET 挑战赛中就以 .NET 6 中的 Minimal API 作为学习的主线来实现相干的云原生利用。有小伙伴问怎么能够用好 Minimal API，如何去架构一个 Minimal API 的云原生解决方案，上面我和大家说说。

对比起传统的 Web API，Minimal API 勾销了 Controller , 文件的组织形式更像 Node.js . 在以前要启动一个 Web API，.NET 对比起 JavaScript , Go , Rust , Python 等语言的 Web 框架还是绝对简单的。.NET 团队心愿通过 Minimal API 简化 .NET Web 框架，让开发者能在一个文件实现简略 API 构建。以下是一个最根本的 Minimal API 我的项目。

MapGet 是 EndpointRouteBuilderExtensions 类的扩大办法，你能够看到它设定了路由规定后，会传递一个委托参数，编译器会将它转换为 RequestDelegate，通过它来取代 Controller 的工作。而后应用 app.Run() 办法来运行咱们的 Minimal API 应用程序。

在传统的 Web API 通过 Controller，针对不同的性能进行 CRUD 的开发，但如果咱们是 Minimal API 呢，要如何组织呢？还有咱们是否还能用 Repository Pattern 呢？

Controller 再见

假如咱们要搭建一个对于课程信息的 API，有课程根本信息 (课程类型，课程列表) 和选课信息(学生选课，每门课学生选课信息)，如果从传统 Web API 你须要增加 CourseController 和 BookController 两个控制器，通过不同 Action 去对应相干路由，但对于 Minimal API 如果咱们波及很多的路由就会让咱们的 Program.cs 文件过大，十分不好治理。那咱们把性能点切分，或者说从新模仿 Controller 去划分还是十分好的。

如上图，是我画的一个图，通过把 Course 和 Book 划分为两个 Module，在 Module 里都蕴含了路由的设置。这个时候咱们做一个接口，因为每个 Module 都须要蕴含增加路由的办法，所以把它做成一个接口 IBaseModule，当前不同的 Module 都能够用。

如何增加进去 Program.cs ? 咱们来用一个 IEndpointRouteBuilder 的扩大办法，把路由增加都归类进来

public static class ModuleExtensions
{public static void Routers(this IEndpointRouteBuilder builder)
    {CourseModule courseModule = new CourseModule();
        BookModule bookModule = new BookModule();
        courseModule.AddModuleRoutes(builder);
        bookModule.AddModuleRoutes(builder);


    }
}

这里有一个技巧就是咱们能够通过以下 typeof 找到继承于 IBaseModule 的 Module 并将它实例化后调用增加路由的办法。

public static void Routers(this IEndpointRouteBuilder builder)
{var modules = typeof(IBaseModule).Assembly
        .GetTypes()
        .Where(p => p.IsClass && p.IsAssignableTo(typeof(IBaseModule)))
        .Select(Activator.CreateInstance)
        .Cast<IBaseModule>();

    foreach(var module in modules)
    {module.AddModuleRoutes(builder);
    }

}

Repostitory 模式能连续吗？

这是毫无疑问能够持续应用。通过 Repository 模式你不须要去关怀你所应用的 ORM 是什么，与 ORM 的所有处理过程都在 Repository 层中解决掉 , 通过这样去缩小耦合，提供更好的可测试性。在微软文档中，有以下的比拟

在 Minimal API 应用 Repository Pattern 在整体上和传统的 http://ASP.NET MVC 没有不同，这里是我用 Repository 模式架构的 Minimal API 的截图

留神一点有人认为 Repository 模式有点过期，和适度架构，但我感觉还是十分有必要的，因为这样能够更好治理你的我的项目。

依赖注入

依赖注入解决了应用程序如何独立于对象创立形式的问题。当您须要可配置的应用程序单元测试时，这十分有用。随着应用程序的规模和复杂性的增长，依赖注入可帮忙您更轻松地更改应用程序。在 http://ASP.NET Core 中有十分好用的依赖注入形式，这点在 Minimal API 也是。因为咱们针对功能模块去治理，所以在依赖注入时也能够针对模块性能去进行。以下是我针对模块依赖注入的设计，联合 Repository 模式以及下面提到的 ModuleExtension.cs 进行的调整，我也把对于数据连贯专用的依赖注入也形象了进去。

public static class ModuleExtensions
{static readonly List<IBaseModule> moduleList = new List<IBaseModule>(); 

    private static IEnumerable<IBaseModule> GetModules()
    {var modules = typeof(IBaseModule).Assembly
            .GetTypes()
            .Where(p => p.IsClass && p.IsAssignableTo(typeof(IBaseModule)))
            .Select(Activator.CreateInstance)
            .Cast<IBaseModule>();

        return modules;
    }

    public static void Routers(this IEndpointRouteBuilder builder)
    {foreach(var module in moduleList)
        {module.AddModuleRoutes(builder);
        }

    }

    public static void AddIoC(this IServiceCollection services)
    {foreach(var module in GetModules())
        {module.AddModuleIoC(services);
            moduleList.Add(module);
        }

    }

    public static void AddGlobalConfig(this IServiceCollection services)
    {services.AddScoped<CourseDataContext>();
        services.AddScoped<IUnitOfWork, UnitOfWork>();}

}

留神一些中央，尽管在 Minimal API 上，咱们的依赖注入尽管把不同的 Services 注册了单例给 RequestDelegate 所调用，但在作为参数传送时，要增加 [FromServices] 属性标签才无效 , 如下

app.MapGet("/Course/GetCourse" ,([FromServices] ICourseService courseService , int typeID)=> {return  courseService.GetCourseList(typeID);
});

在 http://ASP.NET Core 中开发 API 时，你 90% 都在应用 http://ASP.NET Core MVC。而当你应用 http://ASP.NET Core MVC 架构 Web API 时，你会发现有点简单，你须要合乎 http://ASP.NET Core MVC 的所有要求。而 Minimal API 正好解决了这些问题，特地对于一些只做 API 或者入门的开发者，只须要简洁的代码就能实现相似 Node.js 一样的工作。有人问我 Minimal API 会取代传统的 Web API 吗？我能够通知大家不会。还是那句话 , 抉择合乎我的项目需要的办法才是邪道的。

在云原生的年代，Minimal API 是 .NET 的又一把利器。.NET 6 的 Minimal API 要用好，实际上还是用到不少旧常识，像 Module 的构建形式，我参考了开源的 Carter(https://github.com/CarterComm…)，像 Repository 模式还是没有变，当然还是那些相熟的语法 C#，这就是咱们常说的”万变不离其中“。Minimal API 不是要取代 Web API , 更多是给开发人员多一个抉择。作为 .NET 学习挑战赛知识点的补充，心愿能给各位小伙伴更粗浅理解 Minimal API 在理论利用场景的技巧。本次的示例代码也放到我的 GitHub 上了，如果各位小伙伴感兴趣能够拜访该链接获取残缺的代码 https://github.com/kinfey/Min…。

相干资源

学习 Minimal API , 请拜访该链接
学习 Repository 模式，请拜访该链接

关于.net:NET-6-Minimal-API-的经验分享

再来认识一下 Minimal API

架构 .NET 6 Minimal API 我的项目

Minimal API or Web API

小结