旨在提供一组框架约定以帮助你更快速的构建大规模化的应用程序
标准: 实现某个功能的抽象类/接口类
模组: 实现某个标准的类库
插件: 轻量化的模组,一般用于Web服务中,非Web服务运行的必要实现.
例如:JWT身份认证 没有这个功能不影响你的实际业务运行.
在互联网应用大规模化需求逐渐普及的今天,传统的三层架构已经无法满足当下的系统要求.
流量、速度、安全等一些问题日渐凸显,我们希望出现一个可以由开发者自定义程度较高的框架,实现小马拉小车,大马拉大车.
Air.Cloud 包含一组框架标准与一些基础实现,你可以通过实现这些标准或者使用实现这些标准的库来构建你的服务.
这会给你带来玩乐高的体验,通过不同的标准实现库组合的方式,构建可大可小的动态框架,使用这个框架来构建你的服务.
为何Air.Cloud 中包含了Furion框架? Furion框架确实有些优点的地方值得我们学习,吸收百家之长进而不断完善自己的内容.
不,完全不会。 Air.Cloud本身没有实现的功能,他包含一组标准以及一些基本的功能.
你可以把他想象成一个浑身全是接口的插座,我们通过定义标准的方式推动框架更新迭代。
我们充分利用Furion的加载机制对模块进行加载,通过依赖注入的方式将实现的模块进行引入,这通常是使用Air.Cloud的你们决定引用哪个版本或哪个开源参与者的标准实现。
如果不想使用这些实现,你完全可以在Air.Cloud框架内外进行编写属于你自己的模块大作,并通过nuget推广给更多使用Air.Cloud的用户句号
如果你是一个调包侠,那么默认的一些标准实现也是足够你的日常使用的.
如果你是一个轮子怪,那么你可以编写自己的标准实现,并将其分享给其他使用Air.Cloud的用户.
作者本人用过大大小小很多后端框架,但是给我的一个真实感受是有如下两点:
1. 小框架写起来很快,但是很多功能不支持需要自己去捯饬.
2. 大框架写起来很慢,往往一个小功能小服务需要投入更多的时间与精力去维护.
举个例子:
大框架就像是给你一杯加了各种物质的水,你需要去过滤之后才能饮用,删除掉一些无用的组件/注入来到达最佳"饮用"效果.
小框架就像是给了你氧气和氢气,你需要自己去把它变成你所需要"饮用"的水.
那么,Air.Cloud呢?
在设计之处就考虑到了这种情况,我们既不给你一杯加了各种物质的水,也不给你制作水的原材料,
而是给你各种类型的水任你去选择,你想喝什么水,喝多少水由你自己去决定
每个标准的实现都是一个模组,该模组将会发布到nuget上供你选择,nuget就像是一个大货架,你只需要在其中挑选你想要的水就可以"饮用"