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

7次阅读

共计 3933 个字符,预计需要花费 10 分钟才能阅读完成。

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 的云原生解决方案,上面我和大家说说。

再来认识一下 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 应用程序。

架构 .NET 6 Minimal API 我的项目

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

  1. 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);
    }

}
  1. Repostitory 模式能连续吗?

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

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

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

  1. 依赖注入

依赖注入解决了应用程序如何独立于对象创立形式的问题。当您须要可配置的应用程序单元测试时,这十分有用。随着应用程序的规模和复杂性的增长,依赖注入可帮忙您更轻松地更改应用程序。在 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);
});

Minimal API or Web API

在 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 模式,请拜访该链接 
正文完
 0