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 或內部/專有網路服務。
並非所有事物都完美地符合 RESTful/CRUD 模型。有時,您正在整合的服務具有 RPC 風格的介面,其中包含一次性方法。例如,考慮發送電子郵件或讀取連接硬體上的遠端感測器的 API 請求。對於這種情況,您會想要編寫或擴展 machinepack。在此處了解更多關於 machinepack 的資訊。
轉接器主要專注於提供模型關聯的 CRUD 方法。CRUD 代表建立 (create)、讀取 (read)、更新 (update) 和刪除 (delete)。在 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
歡迎您編寫專有的轉接器並以您希望的任何方式使用它們——這些說明適用於發佈開放原始碼轉接器。
npm version patch
。git push && git push --tags
。npm publish
。在建置 Sails 應用程式時,與另一個硬體進行任何非同步通訊的發送或接收,在技術上都可以標準化為一個轉接器(即 API 整合)。
來自維基百科: http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
雖然關聯式資料庫在軟體應用程式中提供了一個常見的持久層,但還存在許多其他持久層。CRUD 功能可以使用物件資料庫、XML 資料庫、純文字檔案、自訂檔案格式、磁帶或卡片等來實作。
換句話說,Waterline 不一定只是您資料庫的 ORM。它是一個與各種 RESTful 服務、資料來源和裝置整合的與目的無關的開放標準和工具集——無論是 LDAP、Neo4J,還是 一盞燈。
但請記住: 僅將 Waterline 轉接器用於與支援「建立」、「讀取」、「更新」和「刪除」介面的資料庫和 API 通訊。並非所有事物都符合該模型,並且有 更好、更通用的方法 來解決那些其他用例。
總而言之,將您的 API 整合編寫為轉接器更容易,花費更少時間,並且吸收了相當大的風險,因為您可以獲得標準化慣例集、已記錄的 API 和 內建社群中其他經歷過相同過程的開發人員的優勢。最棒的是,您(和您的團隊)可以在其他專案中重複使用轉接器,加速開發並節省時間和金錢。
最後,如果您選擇以開放原始碼形式發佈您的轉接器,您將為我們的小框架和我們新興的 Sails.js 生態系統提供巨大的助益。即使不是透過 Sails,我也鼓勵您回饋 OSS 社群,即使您以前從未 fork 過儲存庫——別害怕,這沒那麼糟糕!
Sails 社群共同發佈的開放原始碼高品質轉接器越多,我們在與各種資料庫和服務整合時需要做的重複性工作就越少。我們的願景是讓每個人都能更輕鬆、更少重複地建置伺服器端應用程式,而這是一個社群轉接器(或 machinepack/驅動程式/產生器/視圖引擎/等等)一次一步實現的。
資料庫轉接器的功能與它們連接的服務一樣多樣。也就是說,有一個標準方法庫,以及您應該注意的支援矩陣。轉接器可以實作以下介面中的一些、全部或都不實作,但請放心,如果轉接器實作了介面中的一種方法,它應該實作所有方法。由於限制和/或不完整的實作,情況並非總是如此,但至少應使用描述性錯誤訊息,以使開發人員了解支援和不支援的內容。
如需更多資訊,請查看 Sails 文件,特別是 轉接器介面參考。
如果您正在尋找一些靈感,一個好的起點是核心轉接器。看看 MySQL、PostgreSQL、MongoDB、Redis 或本機 disk。
在 GitHub、Stack Overflow、Google 群組、IRC、Gitter 等平台上存在一個活躍的 Sails 和 Waterline 使用者社群。請參閱支援頁面以取得建議列表。
如果您有一個此處未涵蓋且未解答的問題,並且您認為該問題會為社群增加價值,請隨時發送 PR,將其新增到文件的這個部分。