-
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的束缚。