Sails 使编写自己的数据库适配器变得相当容易。自定义适配器可以直接在您的应用程序中构建 (api/adapters/
) 或作为 NPM 包发布。查看 自定义适配器简介、适配器接口参考 以及 sails-adapter-boilerplate,以获取有关创建自己的适配器的更多信息。
您可以构建适配器的两个不同位置
api/adapters/
文件夹中如果适配器只在一个应用程序中使用(例如现有适配器的短期分支),您可以将其放在 api/adapters/
中。这是您在运行 sails generate adapter
时开箱即用的功能。在这种情况下,适配器的名称由 api/adapters/
内文件夹的名称决定(按照惯例,适配器的入口点应为 index.js
)。
如果您计划在多个 Sails 应用程序之间共享您的适配器,无论是您组织内部还是作为开源包供 Sails/Node.js 社区的其他成员使用,请选择此选项。要使用这种外部化的适配器,您需要执行 npm install your-adapter-package-name
或 npm link your-adapter-package-name
。
在开始编写开源适配器之前,我们建议您在 GitHub 上搜索
sails-databasename
和waterline-databasename
,以查看是否存在项目。如果存在,一般来说,最好与现有适配器的作者联系,并提供贡献而不是启动新项目。大多数开发人员都会欢迎您的帮助,并且联合努力可能会导致更高质量的适配器。如果不存在,我们建议您创建一个新项目,并使用以下约定命名它:sails-databasename
。
在 Sails 中,数据库适配器公开 **接口**,这隐含了实现某些功能的契约。这使我们能够保证跨多个模型、开发人员、应用程序甚至公司的一致使用模式,从而使应用程序代码更易于维护、更高效、更可靠。适配器主要用于集成数据库,但它们也可以用于支持任何纯粹的 RESTful 开放 API 或内部/专有 Web 服务。
并非所有内容都完美地符合 RESTful/CRUD 模型。有时您集成的服务具有 RPC 样式的接口,其中包含一次性方法。例如,考虑发送电子邮件或读取连接硬件上的远程传感器的 API 请求。为此,您需要编写或扩展 machinepack。 在此处详细了解 machinepack.
适配器主要侧重于提供模型上下文化的 CRUD 方法。CRUD 代表创建、读取、更新和删除。在 Sails/Waterline 中,我们称这些方法为 create()
、find()
、update()
和 destroy()
。
例如,MySQLAdapter
实现了一个 create()
方法,该方法在内部使用指定的表名和连接信息调用 MySQL 数据库,并运行 INSERT ...
SQL 查询。
在实践中,您的适配器可以真正做任何它想做的事情——您编写的任何方法都将在原始数据存储对象和使用它们的任何模型上公开。
查看 Sails 文档,或者查看新 Sails 项目中的 config/datastores.js
,以获取有关在 Sails 应用程序中设置此适配器的信息。
在适配器的 package.json
文件中配置您计划支持的接口(以及目标版本的 Sails)
{
//...
"sails": {
"adapter": {
"sailsVersion": "^1.0.0",
"implements": [
"semantic",
"queryable"
]
}
}
}
在您的适配器目录中,运行
$ npm test
您可以随意编写专有适配器并以您希望的方式使用它们——这些说明适用于发布开源适配器。
git remote add origin [email protected]:yourusername/sails-youradaptername.git
)。package.json
中的许可证设置为“MIT”。npm version patch
。git push && git push --tags
。npm publish
。在构建 Sails 应用程序时,与另一台硬件进行的任何异步通信的发送或接收 *从技术上讲* 都可以归一化为适配器(即 API 集成)。
来自维基百科: http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
虽然关系数据库在软件应用程序中提供了一个通用的持久性层,但存在许多其他持久性层。例如,可以使用对象数据库、XML 数据库、纯文本文件、自定义文件格式、磁带或卡片来实现 CRUD 功能。
换句话说,Waterline *不一定* 只是数据库的 ORM。它是一个与各种 RESTful 服务、数据源和设备集成无关目的的开放标准和工具集——无论是 LDAP、Neo4J 还是 灯。
但请记住:只使用 Waterline 适配器与支持“创建”、“读取”、“更新”和“删除”接口的数据库和 API 进行通信。并非所有内容都适合这种模式,并且存在 更好、更通用的方法 来解决其他用例。
概括地说,将您的 API 集成编写为适配器 **更轻松**、**所需时间更少** 并且 **承担了大量风险**,因为您获得了 **一组标准化约定**、**已记录的 API** 以及 **内置社区** 的优势,其他开发人员已经经历了相同的过程。最棒的是,您(以及您的团队)可以在其他项目中 **重复使用适配器**,从而 **加快开发速度** 并 **节省时间和金钱**。
最后,如果您选择将您的适配器作为开源发布,您将为我们的小框架和我们正在发展的 Sails.js 生态系统提供巨大的帮助。即使不是通过 Sails,我也鼓励您回馈 OSS 社区,即使您以前从未分叉过存储库——不要害怕,这并不那么糟糕!
Sails 社区共同发布的开源高质量适配器越多,我们在与各种数据库和服务集成时需要做的重复工作就越少。我们的愿景是让每个人构建服务器端应用程序变得更加有趣、更少重复,而这将一次一个社区适配器(或 machinepack/driver/generator/view engine/etc.)实现。
数据库适配器的功能与它们连接的服务一样多样。也就是说,存在一个标准方法库和一个您应该注意的支持矩阵。适配器可能实现以下接口中的某些、全部或任何一个,但请放心,**如果适配器在一个接口中实现了一个方法,它应该实现 *所有* 这些方法**。由于限制或实现不完整,情况并非总是如此,但至少应使用描述性错误消息来让开发人员了解支持的内容和不支持的内容。
有关更多信息,请查看 Sails 文档,特别是 适配器接口参考。
如果您正在寻找灵感,一个好的起点是核心适配器。看看 **MySQL**、**PostgreSQL**、**MongoDB**、**Redis** 或本地 磁盘。
Sails 和 Waterline 用户的活跃社区存在于 GitHub、Stack Overflow、Google Groups、IRC、Gitter 等。查看 支持页面 以获取推荐列表。
如果您有一个未得到解答的问题,并且您认为这对社区有价值,请随时发送 PR,将它添加到文档的此部分。