python - name - django structure best practice

Django: "proyectos" vs "aplicaciones" (6)

Tengo un "producto" bastante complejo que me estoy preparando para construir usando Django. Voy a evitar usar los términos "proyecto" y "aplicación" en este contexto, porque no tengo claro su significado específico en Django.

Los proyectos pueden tener muchas aplicaciones. Las aplicaciones se pueden compartir entre muchos proyectos. Multa.

No estoy reinventando el blog o foro: no veo que ninguna parte de mi producto sea reutilizable en ningún contexto. Intuitivamente, yo llamaría a esto una "aplicación". ¿Hago todo mi trabajo en una sola carpeta de "aplicación"?

Si es así ... en términos del espacio de nombres project.app de Django, mi inclinación es usar myproduct.myproduct , pero por supuesto esto no está permitido (¡pero la aplicación que estoy construyendo es mi proyecto, y mi proyecto es una aplicación! ) Por lo tanto, me hacen creer que tal vez se supone que debo acercarme a Django al compilar una aplicación por modelo "significativo", pero no sé dónde trazar los límites en mi esquema para separarlo en aplicaciones: tengo muchas de modelos con relaciones relativamente complejas.

Espero que haya una solución común para esto ...

Intenta responder a la pregunta: "¿Qué hace mi aplicación?". Si no puede responder en una sola oración, entonces tal vez pueda dividirla en varias aplicaciones con una lógica más limpia.

Leí este pensamiento en algún momento, poco después de haber empezado a trabajar con Django, y me doy cuenta de que me hago esta pregunta con bastante frecuencia y me ayuda.

Sus aplicaciones no tienen que ser reutilizables, pueden depender el uno del otro, pero deben hacer una cosa.

Si es así ... en términos del espacio de nombres project.app de Django, mi inclinación es usar myproduct.myproduct, pero por supuesto esto no está permitido.

No hay nada como no permitido. Es tu proyecto, nadie te está restringiendo. Es aconsejable mantener un nombre razonable.

No veo que ninguna parte de mi producto sea reutilizable en ningún contexto. Intuitivamente, yo llamaría a esto una "aplicación". ¿Hago todo mi trabajo en una sola carpeta de "aplicación"?

En un proyecto general de django, hay muchas aplicaciones (contrib apps) que se usan realmente en cada proyecto.

Digamos que su proyecto solo realiza una tarea y solo tiene una aplicación (la nombro main medida que el proyecto gira en torno a ella y apenas se puede conectar). Este proyecto también todavía usa algunas otras aplicaciones en general.

Ahora, si dice que su proyecto está utilizando solo una aplicación ( INSTALLED_APPS=''myproduct'' ), entonces, ¿cuál es el uso del project define el proyecto como project.app ? Creo que debería considerar algunos puntos:

Hay muchas otras cosas que maneja el código que no es la aplicación en un proyecto (archivos estáticos base, plantillas base, configuraciones ... es decir, proporciona la base).
En el enfoque general de project.app, django define automáticamente el esquema sql a partir de los modelos.
Su proyecto sería mucho más fácil de construir con el enfoque convencional.
Puede definir algunos nombres diferentes para urls, vistas y otros archivos como desee, pero no veo la necesidad.
Puede que necesite agregar algunas aplicaciones en el futuro que serían realmente fáciles con los proyectos convencionales de django que, de lo contrario, podrían volverse igual o más difíciles y tediosas de hacer.

En cuanto a la mayor parte del trabajo que se realiza en la aplicación, creo que es el caso con la mayoría de los proyectos de django.

¿Qué es lo que le impide usar myproduct.myproduct ? Lo que necesita lograr que consiste más o menos consiste en hacer esto:

django-admin.py startproject myproduct cd myproduct mkdir myproduct touch myproduct/__init__.py touch myproduct/models.py touch myproduct/views.py

y así. ¿ views.py si digo que views.py no tiene que llamarse views.py ? Siempre que pueda nombrar, en la ruta de Python, una función (generalmente package.package.views.function_name) será manejada. Simple como eso. Todo este "proyecto" / "aplicación" es solo paquetes de Python.

Ahora, ¿cómo se supone que debes hacerlo? O más bien, ¿cómo podría hacerlo? Bueno, si creas una parte importante de la funcionalidad reutilizable, como por ejemplo un editor de marcas, es cuando creas una "aplicación de nivel superior" que puede contener widgets.py , fields.py , context_processors.py etc., todo lo que quieras importar.

Del mismo modo, si puede crear algo así como un blog en un formato genérico en las instalaciones, puede envolverlo en una aplicación, con su propia plantilla, carpeta de contenido estático, etc. y configurar una instancia de un proyecto django para usarlo. contenido de la aplicación.

No existen reglas estrictas que indiquen que debe hacer esto, pero es uno de los objetivos del marco. El hecho de que todo, incluidas las plantillas, le permite incluir desde una base común, significa que su blog debe ajustarse perfectamente a cualquier otra configuración, simplemente cuidando su propia parte.

Sin embargo, para abordar su preocupación real, sí, nada dice que no puede trabajar con la carpeta del proyecto de nivel superior. Eso es lo que hacen las aplicaciones y puedes hacerlo si realmente quieres hacerlo. Tiendo a no hacerlo, sin embargo, por varias razones:

La configuración predeterminada de Django no lo hace.
A menudo, quiero crear una aplicación principal, así que creo una, generalmente llamada website . Sin embargo, en una fecha posterior, es posible que desee desarrollar una funcionalidad original solo para este sitio. Con el fin de hacerlo extraíble (ya sea que lo haga o no), tiendo a crear un directorio separado. Esto también significa que puedo descartar dicha funcionalidad simplemente desvinculándolos de la configuración y eliminando la carpeta, en lugar de eliminar las direcciones URL urls.py de una carpeta global urls.py.
Muy a menudo, incluso cuando quiero hacer algo independiente, necesito un lugar donde vivir mientras lo cuido / lo hago de forma independiente. Básicamente, el caso anterior, pero para cosas que pretendo hacer genérico.
Mi carpeta de nivel superior a menudo contiene algunas otras cosas, incluidas, entre otras, guiones wsgi, scripts sql, etc.
Las extensiones de administración de django se basan en subdirectorios. Entonces tiene sentido nombrar los paquetes de manera apropiada.

En resumen, la razón por la que existe una convención es la misma que cualquier otra convención: ayuda cuando se trata de otros que trabajan con su proyecto. Si veo fields.py , de inmediato espero que el código en él sea una subclase del campo de inputtypes.py , mientras que si veo inputtypes.py , es posible que no sea tan claro sobre lo que eso significa sin mirarlo.

Encontré las siguientes publicaciones de blog muy útiles sobre las aplicaciones y proyectos de django:

En principio, tiene mucha libertad con django para organizar el código fuente de su producto.

Una vez que te startproject usar startproject y startapp , no hay nada que te impida combinar un "proyecto" y una "aplicación" en el mismo paquete de Python. Un proyecto no es más que un módulo de settings , y una aplicación no es más que un módulo de models ; todo lo demás es opcional.

Para sitios pequeños, es completamente razonable tener algo como:

site/ models.py settings.py tests.py urls.py views.py

Aquí los creadores de Django señalan esa diferencia ellos mismos . Creo que pensar en las aplicaciones, ya que tienen que ser reutilizables en otros proyectos, es bueno . También una buena forma de pensar acerca de las aplicaciones en Django proporciona aplicaciones web modernas.

Imagine que está creando grandes aplicaciones web dinámicas basadas en JavaScript .

Puede crear luego en la aplicación django nombrada, por ejemplo, "FrontEnd" <- en la aplicación mostrará el contenido.

Luego creas algunas aplicaciones back-end. Por ejemplo, una aplicación llamada "Comentarios" que almacenará los comentarios de los usuarios. Y la aplicación "Comentarios" no mostrará nada. Será solo API para solicitudes AJAX de su sitio web dinámico de JS .

De esta forma, siempre puedes reutilizar tu aplicación "Comentarios". Puede hacerlo de código abierto sin abrir la fuente de todo el proyecto. Y mantienes la lógica limpia de tu proyecto.