Once again, I accidently sent this email. Not a fan of the sensitivity of
the screen on my new phone. Continued below.
I think if you better define an app vs. a model, you'll find that you need
only a few apps.
IMHO, an app should represent a logical segment of your project, broad
enough that a majority of the business logic is self-contained and relies
little on other apps. Apps should be very high level.
Forgot to mention one exception. I always have a 'common' app that contains
all of the models (or views, etc.) used by multiple other applications. In
a majority of cases, these are abstract models I use for all of my concrete
models in other apps that include fields for auditing such as created_by
and created_on. Other examples would include abstract models for addresses,
and master views that include logic such as requiring a user be logged in
used as mixins for other apps.
In your case, you would likely have apps for 'accounting' and
'engineering', along with other distinct units within the business. The
business processes and logic for engineering have little or no overlap with
that of accounting. Same with HR, IT, and so on. That's literally as
detailed as your apps should be, in which case you'll probably end up with
a dozen or so at worst. If it were me, I'd have even less than that with
even larger groupings, maybe something along the lines of 'sales' and
'operations' as the only two apps.
One of the key ideas to help understand here is that a Python file
containing models does not have to be called models.py. In fact, I usually
don't have a models.py at all. Instead, I create a Python module within the
app called 'models', which is nothing more than a directory named 'models'
that contains __init__.py and all of the Python files that contains my
models. Each of those files contains models that are further separated
logically. The structure looks like this (some structure omitted for
brevity):
business_proj/
engineering/
models/
__init__.py
abstract_design.py
abstract_manufacturing.py
abstract_quality_assurance.py
design.py
manufacturing.py
quality_assurance.py
You could also bury the abstract models in their own module using the same
pattern.
Assuming you have 'engineering' as a registered app, your __init__.py would
look
something like this:
from .design import *
from .manufacturing import *
from .quality_assurance import *
This let's Django find all of the models to create the migrations
accordingly.
Imports of these models in other locations can also much more objective:
from engineering.models.design import WidgetOutline
In reality, this also works as an alternative because of the __init__.py
setup:
from engineering.models import WidgetOutline
But that is slightly less verbose. Your call.
Views and forms (and probably URL's) can be organized using the same
pattern. There's no automatic discovery process like models have; views,
forms, and URL's can live anywhere with any legal Python name since they
are manually imported wherever they are needed. Theoretically your entire
project can run inside a single monolithic file.
HTH,
-James
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWDqrGyYuQSb-hfCc73eG0TVut4-QW3HfA3J_6xLyJCNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
