Dudas Django

[Foxandxss]

Voy a instentar solucionarte algunas dudas.

Django es un framework web basado en configuración y no en convención.

Eso quiere decir que a diferencia de Rails, donde cada cosa tiene que ir en un lugar si o si, en Django puedes colocar las cosas como te de la gana y donde te de la gana, siempre y cuando así lo indiques.

Dicho esto, las aplicaciones Django se organizan en apps. Un proyecto puede contener desde 1 a X apps.

Como ya te digo, Django va todo por configuración y puedes moldearlo a tu gusto, pero lo que yo más he visto, es organizar la aplicacion por funcionalidades.

Imagina que vas a crear una tienda, el proyecto se llama "tienda", luego vas creando apps. Si quieres lo metes todo en una app, y si no lo vas separando en funcionalidad, por ejemplo:

Una app para el catálogo (mostrar listado de productos, detalles, etc).
Una app para el carrito de la compra (el carrito en si, enlazarlo con algun sistema de "checkout" ya sea propio o externo...)
Una app para el "checkout" si decides usar el tuyo propio.
Una app para manejar clientes.
Hasta una app para todo el tema de búsquedas.

Fijate como he dividido una aplicación en 5 trozos (que pueden ser más o menos, a gusto del consumidor.

Lo interesante es que por ejemplo puedes usar Google checkout para las compras y te creas un carrito que "hable" con google checkout y te configuras unas clases majas para dicho proceso.

Dentro de un mes te creas otro tipo de tienda, pues puedes coger la app "carrito" y usarla en la nueva tienda y ya está. Al dividir por funcionalidad, se te hace sencillo de reusar mañana.

Ahora respecto a tus preguntas.

1. Admin si es una app "django.contrib.admin". User en si es un modelo pero dicho modelo está dentro de una app "django.contrib.auth" que es la app que controla el sistema de autentificación. No sé si te referías a los que Django a unos que tu vas a crear, si es el segundo caso, pues depende de la aplicación, pueden ser dos cosas diferentes si.

2. Claro que si. APP A puede tener un modelo llamado "usuario" y APP B hace un "from appa.models import usuario" y ya está. Realmente a nivel de programación te da igual tener todo en un mismo .py, en una misma app o hasta en otro proyecto. A través de imports accedes donde quieras.

3. Como ya te digo (aunque en este caso si que pueden ser dos apps), a Django le da igual como te lo organices, Django no te obliga a nada, siempre y cuando se lo digas. Hay gente que en vez de tener un views.py tiene un directorio "views" y dentro un .py por vista. Cuestión de gustos / necesidades.

4. Lo mismo de antes, a Django le da igual lo que hagas, aunque particularmente eso no me suena bien. Mejor una aplicación llamada "usuario" por un lado y por otro lado otra aplicación llamada "reporte". O sea, dentro del mismo proyecto creas todas las apps que necesites para distintas funcionalidades.

5. Ahi me has pillado, no tengo ni idea si puedes dividir apps en distintas bases de datos. Nunca he tenido esa necesidad.

La escalabilidad se encuentra a palos. Personalmente considero mi manera (o la manera de la que yo he aprendido viendo código ajeno) muy buena para escalabilidad, pero dentro de unos años te diré :)

Un saludo.