カスタムアダプター
Sailsを使用して、独自のデータベースアダプターを非常に簡単に作成できます。カスタムアダプターは、アプリで直接作成（api/adapters/）またはNPMパッケージとして公開できます。カスタムアダプターの紹介、アダプターインターフェイスリファレンス、およびsails-adapter-boilerplateを参照して、独自アダプターの作成に関する詳細情報をご覧ください。
アダプターはどこへ置く必要がありますか？
アダプターのビルドは、2つの異なる場所で行うことができます。
アプリのapi/adapters/フォルダー
アダプターは1つのアプリでのみ使用される（たとえば、既存のアダプターの短期フォークなど）場合、api/adapters/を配置できます。これはsails generate adapterを実行したときにすぐに得られる内容です。この場合、アダプターの名前はapi/adapters/内のフォルダーの名前によって決まります（慣習により、アダプターのエントリポイントはindex.jsである必要があります）。
独立したリポジトリ
自社の組織内のみか、大きなコミュニティのSails/Node.jsメンバーのオープンソースパッケージとして、アダプターを複数のSailsアプリ間で共有する場合には、このオプションを選択してください。このような外部化されたアダプターを使用するには、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アプリで設定する方法に関する情報をご覧ください。
テストの実行
サポートするインターフェイス（および Sails の対象バージョン）をアダプターの package.json ファイルで構成します。
{
//...
"sails": {
"adapter": {
"sailsVersion": "^1.0.0",
"implements": [
"semantic",
"queryable"
]
}
}
}
アダプターのディレクトリで次を実行します。
$ npm test
アダプターを公開します。
独自のアダプターを作成して、好きな方法で使用することは歓迎します。これらの手順はオープンソース アダプターをリリースするためのものです。
- 新しい公開リポジトリを作成し、リモートとして追加します（`git remote add origin [email protected]:yourusername/sails-youradaptername.git)。
- 必ず自分を著者として割り当て、package.json のライセンスを「MIT」に設定してください。
- 最後のテストを 1 回実行します。
- ドキュメントに対するプルリクエストを作成し、アダプターのリポジトリを追加します。
- 新しいアダプターに関する情報をドキュメントに追加します。
- 世界中の人々があなたを惜しみなく賞賛します。
npm version patchを実行します。git push && git push --tagsを実行します。npm publishを実行します。
カスタム アダプターが必要になるのはなぜか？
Sails アプリを構築する場合、別のハードウェアとの非同期通信の送受信は、技術的にはアダプターに正規化できます（つまり、API 統合）。
Wikipedia より: 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 コミュニティに貢献することをお勧めします。恐れないでください。それほど悪いことではありません！
Sails コミュニティがオープンソースとして共同でリリースする高品質のアダプターが多ければ多いほど、さまざまなデータベースやサービスと統合する必要がある場合に、私たち全員が行う必要のある反復作業は少なくなります。私たちのビジョンは、サーバー側のアプリの構築をより楽しく、より反復的なものにすることであり、その実現には一度に 1 つずつ、コミュニティ アダプター（または machinepack/driver/generator/view engine/etc.）が必要です。
アダプター インターフェイスとは何ですか？
データベース アダプターの機能は、接続するサービスと同じくらい多様である可能性があります。つまり、標準的なメソッド ライブラリと、知っておく必要のあるサポート マトリックスがあります。アダプターは、以下のインターフェイスの一部、すべて、または何も実装しない場合があります。しかし、アダプターがインターフェイスの 1 つのメソッドを実装する場合、すべてを実装する必要があることに留意してください。制限や不完全な実装が原因で常にそうなるわけではありませんが、少なくともわかりやすいエラー メッセージを使用して、何がサポートされているか、何がサポートされていないかを開発者に知らせておく必要があります。
詳細については、Seils のドキュメント、特にアダプタインターフェースリファレンスをご確認ください。
参照できる例はありますか？
インスピレーションを得たい場合は、コアアダプターから始めるのが良いでしょう。MySQL、PostgreSQL、MongoDB、Redis、またはローカルディスクを確認してください。
どこで助けを得られますか？
GitHub、Stack Overflow、Google グループ、IRC、Gitter などで、SailsとWaterlineのユーザーの活発なコミュニティがあります。サポートページで推奨事項のリストをご覧ください。
ここで説明されていない未回答の質問があり、コミュニティにとって価値があると思われる場合は、お気軽に PR を送信してドキュメントのこのセクションに追加してください。
sailsjs.comで最高のエクスペリエンスを得るには、ブラウザを更新してください。
コンセプト
愛情を込めて作成しました
Sailsフレームワークは、テキサス州オースティンのWebとモバイルショップの協力者の助けを借りて構築されました。2012年に、Node.jsプロジェクトを手助けするためにSailsを作成しました。当然、オープンソースにしました。Sailsが皆さんの生活を多少なりとも楽にしてくれることを願っています！
© 2012-2024 The Sails Company.
Sailsフレームワークは、MITライセンスに基づいて無料でオープンソースです。
イラストは、Edamameです。