浅谈.netCore中的动态API

动态API控制器发现的逻辑

在以往的MVC的架构中，C-控制器这一层的重要性不言而喻，但是在以往的项目中，随着项目的壮大，控制器越来越多，当然也有通过代码的形式去简化Controller的个数，但是也不太友好，经过研究发现一新词（动态API），动态API故名思义就是由应用程序自己去发现控制器接口，当然要让应用程序去发现这一控制器，需要开发人员本身去重新发现方法，如下：

此方法主要继承ControllerFeatureProvider，重写IsController发现方法。根据自身需要书写发现逻辑。
这样我只需要在具体的Application应用程序层只关注我的接口而不在着重关注控制器，我这里个人称之为从MVC（模型-试图-控制器）转变为MVA（模型-试图-应用程序），为什么要这么转变，在搭建传统的MVC框架结构中，C中的控制器中的服务还是需要去调用Service层的服务接口，这样导致C这一层还是要跨一层服务的调用，导致开发者本身着重关注着控制器而不是应用程序本身。转变到MVA，开发者抛弃控制器的理念（不是绝对的抛弃），只着重于应用程序的业务服务本身，可以降低开发的时间和调试成本，从而大大提高开发效率。

发现失败的情况并进行分析

我在搭建动态API的框架中，发现在项目启动后，并没有成功找到Application这一层的Assembly，从而经过AI的建议，逐一排查，发现需要你的服务类必须为public公共出来，并且还需要继承IApplicationPartTypeProvider，但IApplicationPartTypeProvider在NameSpace Microsoft.AspNetCore.Mvc.ApplicationParts下，为AspNetMvc.Core中本身就包含的，而不为特定的程序集。
最后发现要实现动态查找，当然接口的特性需要标注[HttpGet]等请求特性，因为HttpGet在命名空间Microsoft.AspNetCore.Mvc下，从而底层动态查找的时候才能找到此Assembly，从而实现了动态API_Controller的注册。
经过swagger的注入，成功发现接口并调用成功，至此动态API框架搭建成功。
本人一直持续更新动态API对于项目的实战情况更新，暂时先从个人博客项目开始着手，每周进行更新，欢迎访问各位.net大神们提出架构中存在问题的宝贵建议。
保持持续学习的心态！！！
附上：
github地址：https://github.com/wlly3761/Blog；
框架结构贴上：