organización de aplicaciones django

Question

He estado leyendo algunos tutoriales de django y parece que todas las funciones de vista tienen que ir en un archivo llamado "views.py" y todos los modelos van en "models.py". Me temo que podría terminar con muchas funciones de visualización en mi archivo view.py y lo mismo es el caso con models.py.

¿Mi comprensión de las aplicaciones de django es correcta?

Las aplicaciones Django nos permiten separar la funcionalidad común en diferentes aplicaciones y mantener el tamaño del archivo de vistas y modelos al mínimo? Por ejemplo: mi proyecto puede contener una aplicación para recetas (crear, actualizar, ver y buscar) y una aplicación de amigo, la aplicación de comentarios, etc.

¿Puedo mover algunas de las funciones de mi vista a un archivo diferente? ¿Entonces solo tengo el CRUD en un solo archivo?

Answer 1

Primero, los archivos grandes son bastante comunes en python. Python no es java, que tiene una clase por archivo, más bien un módulo por archivo.

A continuación, views, incluso como el estándar utilizado, es un módulo de pitón. Un módulo no necesita ser un solo archivo. Puede ser un directorio que contiene muchos archivos, y __init__.py

Y luego, views.py es solo una convención. Usted, el programador de aplicaciones se está refiriendo a él, y django en sí mismo no se refiere a ningún lado. Por lo tanto, puede colocarlo en la misma cantidad de archivos y derivar las funciones apropiadas para entregar, la solicitud a, en el urls.py

Answer 2

No tienen que ir en views.py. Tienen que ser referenciados allí.

views.py puede incluir otros archivos. Por lo tanto, si sientes la necesidad, puedes crear otros archivos en una aplicación que contenga tus funciones de vista y simplemente incluirlas en views.py.

Lo mismo se aplica a models.py.

aplicaciones Django permite a separar la funcionalidad común en diferentes aplicaciones y mantener el tamaño del archivo de puntos de vista y modelos a un mínimo? Por ejemplo: Mi proyecto puede contener una aplicación para las recetas (crear, actualizar, ver y buscar) y una aplicación de amigo, la aplicación de comentarios, y así en.

No sé acerca de la parte "a un mínimo": algunas aplicaciones son simplemente grandes en vistas, otras grandes en modelos. Deberías esforzarte por dividir bien las cosas, pero a veces solo hay un montón de código. Pero aparte de eso, este es un buen resumen de las aplicaciones de Django, sí.

Answer 3

La respuesta a este question puede ser útil para usted.

Answer 4

También me desagradan los archivos largos.

Por supuesto, lo que se lee en las otras respuestas es cierto, pero explotan algunos muy ingenioso equivalencia pitón:

views.py 

y

views/__init__.py 

son más o menos funcionalmente equivalente - con esto quiero decir que si el que ambos contienen def my_view() continuación

from views import my_view 

funcionará de la misma en ¡ambos casos!

Desde allí es fácil de estructurar sus archivos largos en los más pequeños, pero manteniendo la convención de nomenclatura que todos los desarrolladores de Django se utiliza para:

views/__init__.py 
views/largemodel_view.py 

después en __init__.py no se olvide de importar los puntos de vista de largemodel_view.py .

Con grandes aplicaciones que hacen lo mismo con los modelos, aunque se debe recordar para establecer el Meta.app_name:

class MyModel(models.Model): 
    ... 

    class Meta: 
     app_name = 'yourappname' 

porque Django no recogerlo mágicamente de otro modo para la administración (pero todavía lo cargará, gracias ! a Python)

así que mis aplicaciones por lo general terminan buscando algo como:

project/settings/__init__.py 
       /..othersettings.. 
     /app_1/models/__init__.py 
        /... 
      /views/__init__.py 
        /... 
      /templates/ 
      /static/ 
      urls.py 
     /urls.py 

etc.

aunque, por supuesto, no hay límite (las URL también se pueden dividir, etc.etc)