Несколько функций validate_doc_update в проектных документах CouchDB. Есть хорошие практики?

Question

После прочтения этого абзаца в Руководстве по CouchDB ( здесь ):

Если у вас есть несколько документов дизайна, каждый с функцией validate_doc_update, все эти функции вызываютсяпри каждом входящем запросе на запись.Только если все они пройдут, запись будет успешной.Порядок выполнения проверки не определен.Каждая функция проверки должна действовать сама по себе.

Мне интересно, есть ли полезная практика для работы с несколькими функциями validate_doc_update?

Я имею в виду: лучше создавать толькоодин проектный документ с полем validate_doc_update или с несколькими меньшими?

В первом случае можно быть уверенным, что ни одна из функций проверки не будет мешать другой, но функция может стать очень большой, если многонеобходимы элементы управления.

С другой стороны, некоторые более мелкие функции могут быть проще для чтения и развития, но нужно быть уверенным в назначении каждой функции и не связываться с другими.

Кроме того, какой смысл давать каждому документу проекта функцию проверки?Хранение одного в документе вида кажется, например, немного грязным, но создание нескольких проектных документов только с целью удержания одной маленькой функции проверки мне тоже не кажется очень умным.

Что вы думаете?

Возможно, я что-то упустил, вот в чем вопрос моего вопроса, есть ли какие-либо полезные практики по управлению несколькими функциями validate_doc_update?

Answer 1

Обратите внимание, я написал цитируемый абзац.

В общем, я вижу соотношение 1: 1 между приложениями и проектными документами. Все, что нужно одному приложению, должно быть в одном проектном документе. В более крупных приложениях может потребоваться использование нескольких документов дизайна по разным причинам (например, для разных групп представлений), но, как правило, один документ разработки на приложение является хорошим практическим правилом.

Теперь у вас может быть несколько приложений на базу данных. Например. CMS: одно приложение может быть общедоступным приложением для просмотра CMS, а другое - интерфейсом администратора. Вы хотите разделить их, потому что, в общем, это два разных приложения, которые работают с одними и теми же данными, и держать их отдельно - хорошая организационная идея. Применяются разные механизмы безопасности, поэтому у вас есть две функции проверки, которые реализуют то, что применимо для соответствующего приложения.

Цитируемый абзац - это определение случая, когда у вас (по какой-либо причине) имеется более одного проектного документа на базу данных. Это объясняет, чего ожидать. Это не означает, как разбить вещи на части. Придерживайтесь одного правила оформления для каждого приложения, и в большинстве случаев у вас все хорошо.

Answer 2

Я знаю, что уже был выбран ответ, но я, по крайней мере, выкину свою практику по этому вопросу в качестве альтернативы.

Я решил не создавать только чистые CouchApps, по крайней мере, пока. (Я выбрал Node.JS в качестве своего нового слоя промежуточного программного обеспечения). Имея это в виду, я получаю гораздо больше гибкости от CouchDB Design Documents.

Я перешел к созданию отдельного проектного документа для каждой сущности в моей базе данных. В результате каждый проектный документ содержит свои собственные представления, функции проверки, обработчики обновлений и т. Д. В ответ на ваш вопрос каждая функция проверки имеет дело только с 1 сущностью в моей базе данных, что делает ее более целенаправленной и простой в управлении.