Обикновено се опитвам да избягвам субективните отговори, но това е наистина важен дебат. Първо бих препоръчал да прочетете Meteor Methods vs Client Side Operations от блога Discover Meteor. Имайте предвид, че в Edthena ние използваме методи изключително по причини, които трябва да станат очевидни.
Методи
професионален
-
Методите могат правилно да налагат схема и правила за валидиране с произволна сложност без нужда от външна библиотека. Странична бележка - проверката е отличен инструмент за валидиране на структурата на вашите входове.
-
Всеки метод е един единствен източник на истина във вашето приложение. Ако създадете метод „posts.insert“, можете лесно да се уверите, че това е единственият начин в приложението ви за вмъкване на публикации.
con
- Методите изискват императивен стил и са склонни да бъдат многословни по отношение на броя на валидациите, необходими за операция.
Операции от страна на клиента
професионален
allow/denyима прост декларативен стил.
con
-
Проверка на схемата и разрешенията за
updateоперацията е безкрайно трудна. Ако трябва да приложите схема, ще трябва да използвате външна библиотека като collection2. Само тази причина трябва да ви накара да спрете. -
Модификациите могат да бъдат разпределени във вашето приложение. Следователно може да е трудно да се идентифицира защо се е случила конкретна операция с база данни.
Резюме
Според мен allow /deny е по-естетически приятен, но основната му слабост е в налагането на разрешения (особено при актуализации). Бих препоръчал операции от страна на клиента в случаите, когато:
-
Вашата кодова база е сравнително малка - така че е лесно да се грепвате за всички случаи, в които се появява конкретен модификатор.
-
Нямате много разработчици - така че не е нужно всички да сте съгласни, че има един и единствен начин за вмъкване в X колекция.
-
Имате прости правила за разрешение - напр. само собственикът на документ може да променя който и да е аспект от него.
Според мен използването на операции от страна на клиента е разумен избор при изграждането на MVP, но бих преминал към методи за всички други ситуации.
актуализация на 22.02.15
Сашко Стубайло създаде предложение за замяна на разрешаване/отказване с методи за вмъкване/актуализиране/премахване.
актуализация 6/1/16
Метеорният водач заема позиция, която allow/deny винаги трябва да се избягва.
