2012-01-29 18 views
15

¿Es típico separar la validación de entrada de la validación a nivel de modelo en los proyectos de Django? Por ejemplo, validar que un nombre de usuario se ajusta a los criterios de nomenclatura sería la validación de entrada y verificar que el usuario no esté ya en la base de datos sería una validación a nivel de modelo.Separación de entrada de formulario y validación de modelo en Django?

He estado buscando el código de un compañero de trabajo, y ponen ambos tipos de validación en una clase de formulario (en forms.py). ¿Es esta la configuración típica, o es más común que la validación a nivel de modelo aparezca en el modelo o vista?

¿O hay una mejor manera de acercarse a esto-- como usar un ModelForm? Soy bastante nuevo para Django e intento aprender cuál es el patrón recomendado para esta situación.

Respuesta

12

Esta es una pregunta muy interesante (para mí).

En mi opinión, todos los códigos de validación se deben mover al código del modelo. Esta es la forma de no romper las reglas comerciales. Cuando el código de validación está en el modelo, no es posible olvidar alguna validación en un formulario nuevo o tener reglas inconsistentes en varias formas.

I link para usted 'Django, Raise a validation error in a model's save method' pregunta que se relaciona con la suya. Debajo de la pregunta puede ver cómo mover validaciones de código de formularios al modelo. Espero que esta breve introducción pueda ayudarte.

¿De qué marco de trabajo vienes? ¿Cómo se escriben las reglas de validación en su entorno?

+3

Estoy de acuerdo. La mayoría de las cosas realmente pueden considerarse como validación "a nivel de modelo". Realmente no desea que un nombre de usuario llegue a la base de datos si no coincide con los criterios de nomenclatura. Hay algunas cosas que variarán de una a otra, y es allí donde quiere validar en el formulario en sí. Es posible que tenga un modelo de archivo elegante que contenga el tipo de archivo en un campo. Cualquier tipo está bien en el nivel de modelo, pero en el formulario de carga de fotos que desea limitarlo a png y jpeg, por ejemplo. – dokkaebi

8

No estoy de acuerdo con la respuesta aceptada. Prefiero usar la validación a nivel de modelo para evitar inconsistencias en los modelos, y la validación a nivel de formulario para cualquier restricción específica del sitio.

Supongamos que tenemos un modelo para eventos, con datetime campos para la hora de inicio y finalización. La validación del modelo nos obligaría a tener una hora de finalización posterior a la hora de inicio. Sin embargo, lo dejaría en la forma de validar que el evento recién creado no está en el pasado. Por lo tanto, si alguna vez tengo que agregar un evento que ocurrió en el pasado, podría usar un formulario específico del administrador que permita fechas en el pasado, o simplemente agregarlo directamente a la base de datos.

Por lo tanto, la validación del modelo solo debe verificar los valores que son evidentemente incorrectos. pero si alguna vez necesitas hacer algo funky (personajes Unicode en un nombre de usuario para un bot, por ejemplo), debería permitirte hacerlo, incluso si solo es a través del administrador o el shell. He leído una respuesta en StackOverflow que sugería usar siempre formularios en el código back-end, rellenando campos con código como form["field"] = "value", para beneficiarse de la validación constante.

+1

Para su escenario de ejemplo, puede tener el campo userId en la tabla 'event' y permitir el formulario de llenado con fechas anteriores para algunos usuarios del grupo. Para cada ejemplo que publique puedo encontrar un contraejemplo como este;) Pero este es mi enfoque, estoy seguro de que para algunas reglas, la validación de formularios será la mejor solución. – danihp

+0

Por supuesto, también puede implementarlo en el modelo, pero luego está trabajando en la funcionalidad en algo que debería ser la forma. Si desea volver a utilizar su modelo de Blog en otro lugar, ¿por qué debería importar si la publicación pertenece a un usuario de un grupo llamado "admin"? Dado que este requisito puede cambiar de un sitio a otro, lo mejor es dejarlo en un formulario en lugar de hacerlo en el modelo mismo. – sleblanc

+0

quizás, en el futuro, su aplicación web tendrá una API completa de descanso. Es solo un ejemplo. Gracias por compartir tu commet, es bienvenido. – danihp

Cuestiones relacionadas