AngularJS为啥使用Sails?

前言

伊始Node.js半年,从用Express开发协调的博客到用Sails开发集团项目,深深被Sails震撼了。Sails是Balderdash团队的成品,迅速的类型构建、特出的框架结构还有很多的扩充,让自己有种相见恨晚的感觉。在Koa流行在此以前,个人觉得Sails的用户量依然挺可观的。明日,我想写一写Sails这多少个让我激动的地点,顺便理顺一下Sails的架构。

目录

  • 一步搭建项目
  • 花色架构
  • ORM
  • MVC的实现
  • 路由
  • 安全
  • 日志
  • 单元测试
  • WebSocket

一步搭建项目

在装置了Node.js 和
Sails的环境下,只需要一条命令,就可知搭建一个存有完整架构的体系,虽然这很简短,我如故觉得有必要说一下。

在曾经安装了Node.js和npm的前提下,首先你需要全局下安装Sails
$ sudo npm install sails -g

匡助在一个空路径下,新建一个品种
$ sails new newApp

最终,只需要前往项目路线,把品种周转起来
$ cd testProject
$ sails lift

访问 http://localhost:1337就能阅览一个新的门类

new app

类型架构

.
├── api
│   ├── controllers
│   ├── models
│   ├── policies
│   ├── responses
│   └── services
├── views
├── assets
├── config
├── tasks
├── node_modules
├── package.json
├── Gruntfile.js
├── README.md
└── app.js

api/

api 目录下是你要构建利用的着力所在,常说的MVC的筹划布局就反映在此间
api/controllers
:控制层,该层是Http请求的输入。Sails官方指出该层只处理请求的转化和页面的渲染,具体的逻辑实现应有交由Service(Service)层。
api/models:模型层,在Sails中,对于Model采取的是充血模型,除了可以在模型中定于属性之外,仍是可以够定义包含逻辑处理的函数。在Sails中,所有Model都能够全局性访问。
api/policies:过滤层,该层在Controller层在此之前对Http请求做拍卖,在这一层中,可以定于一些条条框框来过滤Http请求,比如身份认证什么的。
api/responses:http响应的法门都放这里,例如服务器错误、请求错误、404荒谬等,定义在responses文件夹里面的措施,都会赋值到controller层的req对象中。
api/services:服务层,该层包含逻辑处理的方法,在Sails中,所有瑟维斯(Service)都可以全局性访问。

views/

视图层,存放视图模版文件的地点,Sails默认是提供ejs模版引擎的,倘诺你愿意,你可以换成jade、handlebars或者其余你喜爱的模板引擎。

assets/

资源文件夹,在Sails启动的时候,会启动某一个Grunt任务,把assets文件夹里的始末或调减或编译或复制到根目录下的.tmp目录,这是前者可以直接通过路由访问的资源,HTML、JS、CSS以及图片等静态资源都置身这里了。

config/

安排文件夹,在Sails启动的时候,会加载该文件夹里的文件,并赋值在大局对象sails.config中,所以可以在其他一个地方都能用到。在用Sails开发,会时不时跟这一个文件夹里的文本打交道,从config的组合很容易明白Sails都提供哪方面的效劳。

tasks/

Sails自带的门类自动化工具是Grunt,而Grunt的布局和天职注册都位于那些文件夹里了。这里一度提供了一般会用到的CSS编译、JS压缩、文件合并,更改检测等等任务,当然倘诺没有协调索要的,仍可以扩展。

app.js

Sails的开行文件,无论是$ sails lift命令或者$ npm start指令都会运作该公文。

ORM

支付了Sails的公司Balderdash,还开发了一套ORM框架:沃特erline。
沃特(Wat)erline在Sails首要的舞台是在/api/models目录里,在这边定义的模型文件,在Sails启动的时候,都要路过沃特erline的洗礼。
沃特erline 是透过Adapter关联数据库的,不同的Adapter关联不同的数据库。
沃特erline 能适配绝对部分数据库,大致分类两类,一类是官方协会开发的
艾达(Ada)pter适配的,一类是民间开发者开发的Adapter适配的:
官方襄助的:

  • PostgreSQL
  • MySQL
  • MongoDB
  • Redis
  • Disk
  • Memory

民间开发的:

  • SQLServer
  • OrientDB
  • Oracle
  • Cassandra

至于沃特erline的更多信息方可关注:
github:waterline
github:waterline-docs

MVC的实现

在这一段我想不仅仅要谈论到Model层、View层和Controller层,我认为还有必要谈到瑟维斯(Service)层、和Policy层。

Model层

模型文件定义到/api/models中,由沃特erline驱动,所有model都能全局访问。Sails提供命令行创设model的一声令下:$ sails generate model MODEL_NAME

View层

实现在/views中,除了默认提供的ejs模版引擎之外,仍是可以转换成jade、handlebars等模版引擎

Controller层

/api/controller目录里,Sails中提供创制controller的吩咐:$ sails generate controller CONTROLLER_NAME。Sails也提供同时创制model和对应的Controller的下令:$ sails generate api API_NAME

Service层

/api/services目录里,存放自定义的劳动,所有service都可以全局访问,Sails官方的指出是把逻辑处理都放在该层中,Controller层只做路由的散发和轻逻辑的拍卖。

Policy层

/api/policies目录里,存放自定义的过滤器。该层是一条请求在到达Controller在此以前基于需求过滤请求的中间层。在/api/policies目录中定义的公文,还需要在config/policies.js文本中为急需应用到某一过滤器的Action配置。

路由

Sails中要明白路由,首先要记得这一个名词blueprint,中文翻译为:蓝图。我不知晓官方是否表明过怎么要用个单词,但以自家的驾驭,Sails的blueprint是负担指挥每一条客户端请求应该分配到服务器端的哪个Action去,所以叫蓝图吧。
blueprint首要分为三种:RESTful routesShortcut routesAction routes

RESTful routes

当路径诸如:/:modelIdentity 或者
/:modelIdentity/:id的时候,blueprint会依照HTTP的动作(GET、POST、DELETE、PUT等)来分配到对应的Controller下相应的Action来拍卖。例如一个POST请求/user会成立一个用户,一个DELETE请求/user/123会删除id为123的用户。

Shortcut routes

这种路由第一是造福开发,请求的参数可以平昔写在央浼路径中,例如/user/create?name=joe会创立一个新的用户,/user/update/1?name=mike会更新id为1的用户的名字。shortcut
routes在付出条件很有益于,可是在生养条件下需要关闭。

Action routes

这种路由会自动的为Controller层的每一个Action创制一个路由,例如你的Controller层有一个FooController.js,里面有一个Actionbar,那么请求/foo/bar就会分配到barAction。

自然Sails也会提供自定义的路由,用户可以在config/routes.jsconfig/polices.js这六个布局文件中精选关闭或者打开blueprint提供的路由,和概念自己的路由。

安全

要确保产品的安全性,要对两种常见的抨击和安全策略了如指掌,诸如CORS、CSRF、DDOS、XSS等。Sails对于普遍的安全策略都有提供支撑,且只需要经过有关的配备文件就可以控制安全策略的级差。深入探讨Web的安全策略,并不在本文的层面内,日后我会以这一个为题写一篇作品聊聊Web的平安。
想要领悟更多Sails的安全策略可以看看这里:sails:
security

日志

Sails提供了一个大局对象sails.log用来处理日志新闻的输出,日志是分level的,在config/log.js中配备日志输出的level,而level的机能看下表:

Priority level Log fns visible
0 silent N/A
1 error .error()
2 warn .warn(), .error()
3 debug .debug(), .warn(), .error()
4 info .info(), .debug(), .warn(), .error()
5 verbose .verbose(), .info(), .debug(), .warn(), .error()
6 silly .silly(), .verbose(), .info(), .debug(), .warn(), .error()

Sails的日记管理默认是info层的,既会输出.info(), .debug(), .warn(),
.error()的消息。

单元测试

Sails使用了mocha举行单元测试,在新建Sails项目标时候,没有创建单元测试的文件夹,需要自己手动构造单元测试目录,官方指出的目录是这么的:

.
├── api
├── assets
├── ...
├── test
│  ├── unit
│  │  ├── controllers
│  │  │  └── UsersController.test.js
│  │  ├── models
│  │  │  └── Users.test.js
│  │  └── ...
│  ├── fixtures
│  ├── ...
│  ├── bootstrap.test.js
│  └── mocha.opts
└── views

而我在单元测试常用的整合是:mochashouldsupertest
istanbul
内部should是提供断言,supertest是用以测试Controller层的时候伪造http请求的,而istanbul则是提供测试代码覆盖率的。
至于怎么在Sails中编辑测试代码,可以参考
sails:testing

WebSocket

对于有即时性通讯需求的Web应用,我们会用Socket,Sails也为那上头提供了补助。在客户端提供js文件:sails.io.js,而在劳动器端提供全局对象:sails.sockets。通过这六个目的,就足以拓展客户端和服务器端即时性通讯的开支了。
Sails默认会启动WebSocket成效,在客户端访问服务器端的时候,会自行尝试在同域名下连接socket。
值得注意的是,那样会对AngularJS、EmberJS等前端MVVC开发暴发一些阻力。
比如举行AngularJS开发的时候,我们在http://localhost:9000跑AngularJS项目,而服务器端却跑在http://localhost:1337
当访问http://localhost:9000的时候,sails.io.js会尝试于当下路线下开展socket连接,也就是http://localhost:9000,这时会出错,因为服务器是跑在http://localhost:1337的。
在付出的时候要化解这样的问题的时候,我们只需要在AngularJS那边引入sails.io.js日后定义连接路径就行了:

<script src="scripts/lib/sails.io.js"></script>
<script>io.sails.url = "http://localhost:1337";</script>

结语

可以说Sails涵盖了Web开发中会际遇的大举需求和问题,倘诺深远钻研Sails的话,是收益匪浅的。


只要本文对你有用
请不要吝啬你们的Follow与Start
这会大大扶助我们后续创作

「Github」
MZMonster
@MZMonster
JC_Huang
@JerryC8080

相关文章