example - Django. Una aplicación con muchos modelos frente a muchas aplicaciones con modelo único
documentacion de django (4)
Actualmente estoy desarrollando mi propio weblog en Django . Pero ya me pegué al principio. Entonces, aquí está mi jerarquía de árbol:
/pyroot/nemoden/
|~blog/
| |-__init__.py
| |-admin.py
| |-models.py
| |-tests.py
| `-views.py
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|-manage.py
|-settings.py
`-urls.py
Lo que hice fue crear una nueva aplicación llamada blog y describir todos los modelos que necesito para blog en blog/models.py (usuario, publicación, comentario, etc.), pero luego vi Jeff Hui''s video Jeff Hui''s y me di cuenta de que probablemente una mala idea y en Django-world gente no hace eso ... lo que hacemos en ... PHP-world usando PHP Frameworks . Supongo que es mejor haber distinguido las aplicaciones de Django para etiquetas, comentarios, usuarios, etc.
Entonces, lo que estoy preguntando es:
¿Es mejor tener un modelo por aplicación Django? Si es así, ¿hay algunas excepciones cuando no debería crear una nueva aplicación Django para un modelo?
Quiero ir con:
/pyroot/nemoden/
|~blog/ # this is actual application (not a django-application). It uses all the models in views.py, so django-apps becomes just models
| |-__init__.py
| |-tests.py
| `-views.py # all the views (controllers in other frameworks) used by our (well,... my) weblog
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|~post/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-models.py # only Post model goes here
| `-views.py
|~tag/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-tag.py # only Tag model goes here
| `-views.py # <---- I don''t know why we still need it here!
|-manage.py
|-settings.py
`-urls.py
Como ve, admin.py models.py y admin.py de la aplicación de blog , por lo que ahora la aplicación de blog parece más a the app o main app si lo desea, que usa todos los modelos (django-apps) y consiste principalmente en views.py . Y creo que ahora no necesitamos todas las views.py en todas django-apps (sin embargo, este está bajo un GRAN signo de interrogación, es solo en teoría).
¿Mi enfoque es bueno o tendré problemas invisibles para mí ahora, tal vez?
Lo siento si mi pregunta no es lo suficientemente clara, si es así, por favor, coméntela a continuación, la editaré para que sea más comprensible.
¿Hay mejores prácticas?
Gracias.
¿Es mejor tener un modelo por aplicación Django?
Una de las ideas clave para una aplicación reutilizable es: hacer una cosa, y hacerlo bien
Si una aplicación necesita varios modelos (PostEntry, PostAuthor en el caso de una aplicación de blog), esto de ninguna manera es malo. Sin embargo, las etiquetas, las categorías y los comentarios representan características distintivas que, idealmente, pueden reutilizarse en otro contexto y, por lo tanto, deben distribuirse como aplicaciones independientes.
¿Hay mejores prácticas?
Para hacerse una idea de una buena organización de aplicaciones, primero veré las convenciones de aplicaciones reutilizables de Django .
Entonces estás listo para la charla de James Bennett sobre las aplicaciones de valor añadido de DjangoCon 2008 ( Slides ). Otra visión más reciente sobre el mismo tema es el modelo de aplicación Pluggable Django de PyCon 2011
Encontré a este tipo en youtube, que dice que ha lidiado con este problema exacto: ambos tienen una gran aplicación y muchos pequeños que él considera que no son buenos.
http://youtu.be/URztqq1kiqI?t=22m39s
Desde mi propia experiencia: no quieres una aplicación grande, porque las personas pueden manejar mejores árboles de carpetas que se extienden un poco, pero no demasiado. Además, tener una aplicación dificultaría comprender cuáles son los componentes de tu proyecto (para personas nuevas)
Por otro lado, cuantas más aplicaciones tenga (que sí dependen unas de otras), más posibilidades tendrá de tener problemas circulares de importación. Entonces necesitas una estrategia para evitar estas cosas. Aquí también, los miembros más nuevos tenderían a generar problemas en el proyecto.
En general, las personas que han desarrollado en más proyectos, durante más tiempo, por lo general deberían ser quienes toman decisiones arquitectónicas.
La regla de oro es que una "aplicación" debe ser una pieza completa de funcionalidad. Si tu blog no puede ejecutarse sin etiquetas (como literalmente, no solo sería mejor tener un blog con etiquetas que sin ellas), las etiquetas deberían formar parte de la aplicación del blog.
Sin embargo, no hay una respuesta clara aquí. Algunos puristas de aplicaciones se centran por completo en la reutilización y convierten cada aplicación en una pieza discreta de funcionalidad con poca o ninguna dependencia en otra cosa. Algunos crean aplicaciones completas con una sola aplicación de Django. Depende de usted decidir qué tiene más sentido en su situación particular.
En general, diría que se combinan funcionalidades que probablemente no se usen más, pero se requieren para la aplicación, todo en la misma aplicación. Cosas como etiquetas o comentarios son probablemente candidatos para sus propias aplicaciones, y de hecho, puede encontrar muchas de esas aplicaciones disponibles que pueden simplemente conectarse a su aplicación para proporcionar esa funcionalidad.
En cualquier aplicación más complicada que una simple lista de cosas por hacer, inevitablemente vas a terminar con una buena dosis de cruce. No hay una respuesta correcta. Simplemente use el sentido común y piense SECO (no se repita) y lo hará bien.
Nemoden, tu enfoque para cambiar el árbol del proyecto es correcto . Debería dividir su aplicación en funcionalidades más pequeñas ya que esto le permitirá hacer que su aplicación sea más modular y el código será más reutilizable en el futuro.