通常、私は主観的な答えを避けようとしますが、これは本当に重要な議論です。まず、DiscoverMeteorブログからMeteorメソッドとクライアント側の操作を読むことをお勧めします。 Edthenaでは、明らかになるはずの理由でメソッドを排他的に使用していることに注意してください。
メソッド
プロ
-
メソッドは、外部ライブラリを必要とせずに、任意の複雑さのスキーマと検証ルールを正しく適用できます。補足-チェックは、入力の構造を検証するための優れたツールです。
-
各メソッドは、アプリケーションの信頼できる唯一の情報源です。 'posts.insert'メソッドを作成すると、それがアプリで投稿を挿入する唯一の方法であることを簡単に確認できます。
con
- メソッドには命令型のスタイルが必要であり、操作に必要な検証の数に関連して冗長になる傾向があります。
クライアント側の操作
プロ
許可
/拒否
シンプルな宣言型です。
con
-
update
でスキーマと権限を検証する 操作は非常に困難です。スキーマを適用する必要がある場合は、collection2などの外部ライブラリを使用する必要があります。この理由だけで一時停止する必要があります。 -
変更は、アプリケーション全体に広げることができます。したがって、特定のデータベース操作が発生した理由を特定するのは難しい場合があります。
概要
私の意見では、 allow
/拒否
は見た目が良くなりますが、基本的な弱点は、アクセス許可の適用(特に更新時)にあります。次のような場合は、クライアント側の操作をお勧めします。
-
コードベースは比較的小さいため、特定の修飾子が発生するすべてのインスタンスを簡単にgrepできます。
-
開発者はそれほど多くないので、 Xに挿入する方法が1つしかないことに全員が同意する必要はありません。 コレクション。
-
簡単な権限ルールがあります-例:ドキュメントの所有者のみがドキュメントのあらゆる側面を変更できます。
私の意見では、MVPを構築するときはクライアント側の操作を使用するのが妥当な選択ですが、他のすべての状況ではメソッドに切り替えます。
更新2/22/15
Sashko Stubailoは、許可/拒否を挿入/更新/削除メソッドに置き換える提案を作成しました。
2016年6月1日更新
流星ガイドは、許可/拒否コード>の位置を占めます 常に避けるべきです。