I'm doing a project as a study to apply what I've learned so far with Django. My question is: what is the best way to target the project in apps ? If you want to give an example so that something empirical is captured, let's say the project is from a library, where there will be books, authors, employees, where those who wish can through a register register the books, etc. How would you split this project into apps ?
What is the best way to split a Django project into apps?
3
asked by anonymous 12.03.2015 / 22:30
1 answer
1
It is not possible to respond generically, as this depends much more on the domain being modeled, as well as on your goals with the project.
At first, it's okay to have a single app for the entire project. If your models.py is getting too large, you can break it into smaller files. The same goes for views.py , etc:
app
|- __init__.py
|- urls.py
|- admin.py
|- models
| |- __init__.py
| |- a.py
| |- b.py
| |- c.py
|- views.py
If you do this, your models/__init__.py should import all others, so that Django finds its models:
from .a import *
from .b import *
from .c import *
And each model of these submodules must have a class Meta indicating what its app (Source: this answer in SOen ):
class Livro(models.Model):
...
class Meta:
app_label = 'minhaapp'
Whether or not this is a good practice is debatable. But it's a possibility.
And when is using apps definitely better?
When you reuse part of the code in another project, and part of it does not; an app can be redistributed separately from the rest, and used in another context to compose another system.
If you believe that one day you might want to develop software for a bookstore, where books, authors, etc. still exist, but you do not borrow books there, you sell them, so it's worth putting the register and book) separately from the one that simply catalogs the books.
Likewise, the code you write to manage employees can be useful in even more contexts, so it's worth having a separate app for that too.
When there is a dependency hierarchy clear. At first, nothing prevents app A depends on B , and B also depends on A (for example, a A has a foreign key for% model of B and vice versa). But that brings some headache when it comes to making imports , or when deciding which app to include first in settings.py . If the models are tightly coupled, best leave it all in one app just ...
But if you can identify a set of models that only depend on each other, and no more, and another distinct set that depend on each other and some models of the first set, etc., it gets more organized divide them into two apps where the first one is dependency for the second. By creating and maintaining a simple hierarchy you even force yourself to keep your project organized, and whenever there is a "temptation" to introduce a reverse dependency, you are forced to rethink your design. It gives more work, yes, but the end result pays off (the project maintainability becomes easier).
In the absence of other restrictions, you can make other divisions more or less arbitrary, following only your feeling . If an app has too many templates, for example, you may want to split it to make it easier to organize. Or if two models seem to belong to sufficiently distinct domains (eg, books vs. employees), you may want to separate them, even though there are a few models altogether (you can even create apps without no template - only with helper, views, for example, or commands). These are some criteria, but there could be others. You can not even list all the situations, but the two criteria above should give you a good guide.
13.03.2015 / 01:15