-
Notifications
You must be signed in to change notification settings - Fork 19
Home
目前的底层web框架相对较多,有express, koa, restify, loopback等。
而上层的相对比较少,而有的也特别的集成,比如Metoer,Sailsjs,不够灵活,耦合度很大,
要么就是某号称企业及框架,而实际却是在走几十年前走过的老路的一些框架,没有任何的新意,搞低水平重复建设,并且他们都是基于最基本的MVC理论的。
而MVC理论并不是一个精细的理论,最基本的MVC框架是不能胜任复杂的Web业务的,因此很多重复冗余的代码随便可见。
所以vig的目标是解决那些重复性的工作,让我们的Web服务器开发变得更加的简单。
让vig成为一个以Web业务为主要目标,但是同时能兼顾websocket或者基础协议(如tcp/udp)的框架。也就是一个最终可以实现协议无关的框架。
做到协议透明,就是无论你使用的是tcp/udp/websocket/http,都可以使用vig框架统一完成产品逻辑。
所以我们即要将网络的服务进行抽象化,同时也要将Web业务抽象化,并将他们中的常规业务进行模块化的拆分,抽象,
并最终设计出来一个即更加符合Web的理论与实践,又可满足基础socket协议(TCP/UDP)连接服务的框架。
vig放弃了传统的,简单的MVC理念,而是采用了更加细致的业务模型,并且主要关注于服务器开发的C端(传统的Controller)。
但是因为C其实是非常复杂的,所以我们会看到传统的框架的C端各种的不给力,一堆堆的框架都没有解决Web业务本身的常规事务与冗余的问题。
更可笑的是有人将Controller当成是业务对象来看待,将产品业务与Web业务混淆,让代码混乱不堪。
所以vig在里,所有的概念都是产品业务无关,也没有纯的Controller的说法。 因为vig要解决的问题,都是Web业务的问题,暂时与你的产品业务没有任何关系。vig做的事情,只是让你在产品开发时:
(Web)服务器端的业务更加的健壮,控制更加的方便,表现的更加的良好,开发更加的容易,代码更加的简洁,效率更加的提高,速度更加的快捷,模块更加的可复用。
vig中并不会有单独的类叫控制器,因为整个框架的内容就是围绕着控制器的,
所以整个框架并不会有控制器的定义,而是会有下面这些阶段的各类定义:
Requst => 中间件 => 安全/策略 => 条件判断 => 数据校验 => 路由管理 => 业务响应 => 业务处理 => 业务输出 => 输出处理(错误/数据渲染/API) => Response
这个过程我们称之为Web直线
。
vig并不是不认同MVC理念,而是认为MVC理论是一个宏观的理论,现在我们将它分解了,更加的专注于C端。
-
性能超强
默认与基本框架的速度是一样的。因为所有的中间件或者功能都是可选的,这样可以有效的提高框架的性能。而由于vig的主动管理,与分层中间件能力,通常性能要比基本框架构建的服务器的性能要好很多。
-
代码简洁
由于vig默认将代码复用放在非常重要的位置的,各类组件是可以基于字符给出,所以可以节约很多重复代码。
-
刀片式处理方式
vig的处理是基于配置的,当有配置时,才会触发相应的处理。从而不同路径上的处理是不一样的,可以有效的提高系统的吞吐能力
-
架构优雅
vig即有基础框架的性能,又具有大型框架的功能,并且还易于编写,有非常好的扩展性,兼容性。即支持新技术,又能完美的应对已有的技术。
-
提倡业务模块化导向
vig提倡以URL为业务基础,在URL上构筑业务能力,即一个性质的业务处理就是一个/组URL。
-
精细化C端
vig之前,C端总是通过一个简单的Controller来表达的。而实际上却忽略了Web业务与产品或者项目业务之间的差别。用一个非常简单的Controller来表达复杂的Web请求,以及业务处理,显然是不够的,是错误的。而vig试图将Controller精华准确化。并区分项目/产品业务的C端与Web的C端,并努力将Web的C端做好。
-
组件化/微服务化
vig的任何一个独立的业务都是可以直接拿过来使用的,或者组合使用。也就是说,任何一个URL的处理代码,可以轻松的组件出来一个新的服务器,同时可以被别的组件所调用。
- 标准的错误处理
通常现有的框架是不包括错误的统一定义与处理的,而vig提供了统一的处理,让你可以更好的定义,生成,复用,分享,处理错误,并统一输出格式。
- 数据的统一校验
vig的数据校验功能非常强大,可以很方便,而又很简单的对输入数据进行处理。并且还可以添加出错后的处理函数,从而不会影响到基本处理代码。让代码更加的优雅,简洁。
- vig不支持前端开发(除了对websocket的互操作有约定外)
- vig不是服务器(vig不做底层的HTTP协议处理,包括对端口的侦听)
- vig不做ORM(但是会选择当前最适合的ORM做为默认的ORM)
可以。vig是兼容性非常好的框架。他可以和平的与现有的代码共处,通常不会产生任何问题。作者开发的过程中,还是js与ts以及原来的代码多种类型混合开发的,vig是一种非常干净的框架,不会干扰现有的代码,并且任何一个vig模块也是有很好的独立性的。
当然是支持的,作者的项目的所有router都是使用了async/await的,因为我是使用ts开发的。 通常对于get处理:
// routers/get.ts/js
export = async (req, res, scope) => {
let users = await req.models.User.find();
res.send(users);
}
即可。
对于现在常见的Web模型,他通常包括如下的内容:
- 请求与返回(Request & Response)
- 前端与后端(Frontend & Backend)
- 数据库抽象与业务逻辑的连接(Database Design & Business Logic analystics)
- 安全策略与权限管理(Security & Privileges)
- 共享用户与单点登录(User Sharing & Autchenication)
- 配置动态化与自动化( Configuration & Automation)
- 标准化接口(API Standardization)
- 模块化与独立化,可分布式化(Modulization,Indepency, Distribution)
- 错误返回(Error Response)
- 文件上传与云传输(Cloud File Distribution)
所以我们在设计这个框架时,将会着重关注以上的几点。 并努力的将这些核心内容接口化,标准化,从而方便迁移与升级。
vig 框架的原型已经在vigor框架得到应用。
vigor项目地址: https://github.com/calidion/vigor
原型代码地址:
单一文件版: https://github.com/calidion/vigor/tree/master/lib/v2
目录版: https://github.com/calidion/vigor/tree/master/src
express
https://github.com/calidion/errorable
vig自已经定义的vig api标准(原名egg api)。 egg api是一个实用的api标准,不会象restful那样极端,也不会像graphql那样复杂。
vig推荐的api是vig api,但是vig不会限制任何其它的可能性。
项目地址:
https://github.com/calidion/vig-api
采用file cloud uploader
项目地址:
https://github.com/calidion/file-cloud-uploader
sailsjs是一个很前卫的框架,但是sailsjs的集成度过高,不利用于Web业务的拆分。 同时因为nodejs本身的积累相对比较少,模块的成熟度并不高,因些有时候一个可替换能力是非常重要的。 所以vig会尽量优先考虑降低耦合性,目标将几大模块的接口进行标准化。 目前我们在使用sailjs的时候已经发现了很多因为集成度过度导致的问题,所以解耦合是这个框架的主要目标之一。 而vig项目的原因就是我们使用了sails框架,会受到sailsjs的束缚。