基本的な Parties Meteor の例 ( http://meteor.com/examples/parties ) を実行すると、
Meteor.methods を使用する代わりに Collection.allow を使用して挿入、更新などを指定し、クライアントから Meteor.call を発行する必要があるのはなぜでしょうか。
「メソッド」の方法は、より柔軟であるため（つまり、カスタム関数）、常に優れているようです。
質問する
1421 次
2 に答える
8
許可および拒否インターフェイスは、必要なほとんどのアクセス制御に十分な柔軟性を備えています。ビルトインを使用できれば、最終的にはよりクリーンで、より理解しやすく、より読みやすいコードになります。また、クライアント上でデータベース操作を直接実行できるという Meteor の「どこでもデータベース」の抽象化を維持するという点で、より Meteoric です。
コレクションに対するすべての操作を拒否し、メソッドを介してコレクションへのアクセスのみを公開することができます。しかし、最終的に CRUD インターフェースを再実装することになる可能性は高く、おそらく許可機能と拒否機能を再実装することになるでしょう。
allow および deny インターフェースを介して必要なアクセス制御を表現するのが難しい場合にのみ、Meteor.methods を使用するようにしています。たとえば、関連する 2 つのコレクションを一度に更新する必要があり、操作を続行するかどうかを決定する前に、検証で両方のコレクションに対する提案された変更を調べる必要がある場合があります。Meteor.method を使用すると、よりクリーンになります。
于 2013-02-08T23:00:48.483 に答える
0
Collection.allow の目的を誤解しています。これは、クライアント側のコードによってコレクションに対して実行できる操作を制限するために使用されます。これらの制限はサーバー側には適用されません。そして、Meteor.methods でコレクションに対して書き込み操作を実行し、クライアント コードから呼び出す必要があります。
Collection.allow は、エンドユーザーや潜在的なハッカーがあなたのデータを好き勝手に操作できないようにするためのものです。クライアント側のコードは調整できることを忘れないでください。
あなたが言及した例では、パーティー構造に別のフィールドがあるとします。私がこのフィールドを更新できるようにしたくないかもしれません。パーティのフィールド名に対する「更新」コールバック テストがなければ、そのフィールドに変更を挿入することができます。
ポイントを取得しますか？
于 2013-02-08T01:25:21.517 に答える