On Tue, Aug 22, 2017 at 12:37 PM, Alexander Joseph < alexander.v.jos...@gmail.com> wrote:
> Thanks for all the advice. > > One more question - could project structure be causing issues with > migrations? I'm working on a large project and many apps in my project have > several layers of "sub-apps". My structure looks something like this... > Possibly, especially if you're introducing any import loops. It's easy to do. Trying to get the autodiscover mechanism for models to run through nested apps can also be fun. <snip> A few things about my structure - I read in "2 Scoops of Django" that, in > general, if you have more than 5 models per model file then you should > think about splitting the model up into different apps, rather than having > long models files. And I structured it this way so that it would be a > little easier to manage - instead of having all apps under the project > folder, engineering apps would belong in the engineering folder, etc. > > Thanks again > > It depends. Your structure will likely change throughout the life of your project. Start with what you have now and mold accordingly. Loose coupling is key, though, to make it easier to move things around. Like I mentioned in your other thread, you need to redefine what you are considering an 'app'. Your current definition is way too specific/narrow, which is why you are ending up with so many. Almost certainly each product does not need its own app. That's not to say you shouldn't break them apart. I'm saying keep your 'apps' generalized (ie engineering, accounting, etc.) and break up the models into importable Python modules with a sensible structure. Using modules will alleviate much of the pain of the app and model discovery process using the pattern I described in the other thread. It also provides a mechanism for loose coupling, and keeps your models in separate files/folders using any structure you'd like. Reducing the number of apps also reduces the number of files present in your project, since you only need a single apps.py for a larger app, rather than managing 20 apps.py files for 20 smaller apps. 2SoD is an excellent resource, and in no way to do I claim to have a modicum of the knowledge and experience that the authors do. I don't even program for a living. I have a copy for 1.8. You will notice in the book that they do not have separate apps for an ice cream cone vs. ice cream sandwiches vs. toppings, even though these may be analogous to your product_1, product_2, etc. It's hard to tell though, because I'm assuming you generalized your structure, so I don't know if you are talking about different ice cream-based treat types, or cars vs. rocket ships. The latter would likely use separate apps because there would be little overlapping workflows and logic, along with multiple models associated with each. I'd recommend looking in to some introductory material on database normalization, not so much for the mechanics, but rather more conceptually. The way you would break things apart for normalization often coincides neatly with the way you should break apart apps (and builds your model list for you), somewhere around the 2nd normal form. Again, your structure will likely change as you go, so use the loose coupling via the __init__.py module imports as I've shown, and that should help with the transition. -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%2BciV7tZS8WJeFyn1p5MQrctM6pympBPK2btm38FshX%3DSX1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
