Разделение ввода формы и проверки модели в Django? - PullRequest
17 голосов
/ 30 января 2012

Типично ли отделять проверку ввода от проверки на уровне модели в проектах Django?Например, проверка того, что имя пользователя соответствует критериям именования, будет проверкой ввода, а проверка того, что пользователя еще нет в базе данных, будет проверкой на уровне модели.

Я смотрел на коллегукод, и они помещают оба типа проверки в класс формы (в forms.py).Является ли это типичной установкой или для модели или представления чаще встречается валидация на уровне модели?

Или есть лучший способ приблизиться к этому - например, использовать ModelForm?Я довольно новичок в Django и пытаюсь понять, какой шаблон рекомендуется для этой ситуации.

Ответы [ 2 ]

13 голосов
/ 30 января 2012

Это очень интересный вопрос (для меня).

По моему мнению, весь код проверки должен быть перенесен в код модели. Это способ не нарушать бизнес-правила. Когда код проверки находится в модели, невозможно забыть некоторую проверку в новой форме или иметь несовместимые правила в нескольких формах.

Я ссылаюсь на вас 'Django, Поднимите ошибку проверки в методе сохранения модели' , который относится к вашему вопросу. Ниже вы можете увидеть , как переносить проверки кода из форм в модель . Я надеюсь, что это краткое введение может помочь вам.

Из каких рамок вы пришли? Как правила проверки написаны в вашей среде?

8 голосов
/ 02 февраля 2013

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

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

Таким образом, проверка модели должна проверять только те значения, которые явно ошибочны. но если вам когда-нибудь понадобится что-то напуганное (например, символы Unicode в имени пользователя для бота), оно должно позволить вам это сделать, даже если это происходит только через администратора или оболочку. Я прочитал ответ по StackOverflow, в котором предлагалось всегда использовать формы в бэкэнд-коде, заполняя поля кодом, подобным form["field"] = "value", чтобы получить пользу от последовательной проверки.

...