Normalement, j'essaie d'éviter les réponses subjectives, mais c'est un débat vraiment important. Je recommanderais d'abord de lire Meteor Methods vs Client-Side Operations sur le blog Discover Meteor. Notez que chez Edthena nous utilisons exclusivement des méthodes pour des raisons qui devraient devenir évidentes.
Méthodes
pro
-
Les méthodes peuvent appliquer correctement le schéma et les règles de validation d'une complexité arbitraire sans avoir besoin d'une bibliothèque extérieure. Remarque :la vérification est un excellent outil pour valider la structure de vos entrées.
-
Chaque méthode est une source unique de vérité dans votre application. Si vous créez une méthode "posts.insert", vous pouvez facilement vous assurer qu'il s'agit du seul moyen dans votre application d'insérer des publications.
contre
- Les méthodes nécessitent un style impératif et elles ont tendance à être détaillées par rapport au nombre de validations requises pour une opération.
Opérations côté client
pro
allow/denya un style déclaratif simple.
contre
-
Validation du schéma et des autorisations sur une
updatel'opération est infiniment dure. Si vous devez appliquer un schéma, vous devrez utiliser une bibliothèque externe telle que collection2. Cette seule raison devrait vous faire réfléchir. -
Les modifications peuvent être réparties sur l'ensemble de votre application. Par conséquent, il peut être difficile d'identifier pourquoi une opération de base de données particulière s'est produite.
Résumé
À mon avis, allow /deny est plus esthétique, mais sa faiblesse fondamentale réside dans l'application des autorisations (en particulier sur les mises à jour). Je recommanderais les opérations côté client dans les cas où :
-
Votre base de code est relativement petite - il est donc facile de grep pour toutes les instances où un modificateur particulier se produit.
-
Vous n'avez pas beaucoup de développeurs - vous n'avez donc pas besoin d'être tous d'accord qu'il n'y a qu'une seule et unique façon d'insérer dans X collecte.
-
Vous avez des règles d'autorisation simples - par ex. seul le propriétaire d'un document peut en modifier n'importe quel aspect.
À mon avis, l'utilisation d'opérations côté client est un choix raisonnable lors de la création d'un MVP, mais je passerais aux méthodes pour toutes les autres situations.
mise à jour 22/02/15
Sashko Stubailo a créé une proposition pour remplacer allow/deny par des méthodes insert/update/remove.
mise à jour 01/06/16
Le guide météore prend la position qui allow/deny doit toujours être évité.
