template - httpresponseredirect django example
Django: rompiendo vistas (3)
Esta es realmente una pregunta de "mejores prácticas" ...
Encuentro que al desarrollar una aplicación, a menudo termino con muchas vistas.
¿Es una práctica común dividir estas vistas en varios archivos de vista? En otras palabras ... en lugar de tener solo views.py, ¿es común tener views_1.py, views_2.py, views_3.py (pero el nombre es más apropiado, quizás por categoría)?
Dividiendo views.py
La mayoría de su código probablemente espera que sus vistas sean accesibles como myapp.views.viewname . Una forma en que he visto a la gente dividir sus vistas pero manteniendo este nombre de Python es crear un directorio de views/ . views/__init__.py tendrá:
from .foo_views import *
from .bar_views import *
from .baz_views import *
Luego, en views/foo_views.py , coloque:
def foo_detail(request, ...):
# your code here
def foo_list(request, ...):
# your code here
def your_other_view(...):
# ...
Así que mueves todo desde views.py a los archivos en este directorio, haces __init__.py , borras views.py , y listo.
Luego, cuando import myapp.views , myapp.views.foo_detail hará referencia a la función que definió en views/foo_views.py .
Dividiendo otros modulos
Esta estrategia también debería funcionar bien para admin.py , etc. Pero si desea dividir models.py esta manera, deberá agregar app_label = ''your_app_name'' a la class Meta: de todos sus modelos. Por ejemplo, unicorn_app/models/unicorns.py podría tener una entrada como esta:
class Unicorn(models.Model):
description = models.CharField(max_length=80)
class Meta:
app_label = ''unicorn_app''
(De lo contrario, Django imagina que el modelo Unicorn es parte de una aplicación de Django llamada "modelos", que confunde el sitio de administración. De la versión 1.6, la próxima versión 1.7 eliminará este requisito ).
Como guía general, piense en la legibilidad y la capacidad de mantenimiento : el valor predeterminado "views.py" es solo una sugerencia hecha por el andamiaje inicial, no tiene que atenerse a ella.
Por lo general, los archivos con miles de líneas de código son difíciles de mantener, por lo que generalmente trato de descomponer los módulos más grandes en otros más pequeños.
Por otro lado, la división debería tener sentido: dividir las funciones relacionadas en varios archivos, con muchas importaciones que pueden dificultar aún más el mantenimiento.
Finalmente, también puede pensar en otras formas de simplificar su aplicación.
¿Ves código duplicado? ¿Tal vez alguna funcionalidad podría moverse en una aplicación completamente diferente? Y así.
Otra opción sería mover parte de la funcionalidad a una o más aplicaciones. Esto le permitiría mover también formularios y plantillas y mantener las cosas estructuradas. No necesariamente tiene que mover los modelos, lo que le ahorra el modelo y la migración de datos.
Por ejemplo, podría tener la siguiente estructura:
main_app/
|_models.py
|_views.py
|_forms.py
|_urls.py
|_templates/
sub_app_1/
|_views.py
|_forms.py
|_urls.py
|_templates/
sub_app_2/
|_views.py
|_forms.py
|_urls.py
|_templates/