When do I need a new app within the site?

[Cictani]

Hi,

I'm just beginning developing a new app(s) and I'm wondering when I need to add a new app. if one app uses models from another app is that a hint that these two apps are acutally one app or is this still ok in terms of good design?

Let's say I have a customer app (with customer models, admins etc) and a booking app which of course uses the customer model. Would it be good to have two apps or would it be actually only a booking app which includes all the models, logic etc from the customer app?

Thanks in advance

Andreas

[Bill Torcaso]

This is an indirect reply --- but I like the book "Two Scoops of Django".  It is a strong explanation of Django best practices.  (The "scoops" are scoops of ice cream in the fictional ice cream store of the examples).

Hope this helps.

[Julio Biason]

Hi Andreas,

My rule of thumb is "does this works without the other?" Do your customer app works without the booking app? Then they are two different apps, with the second using the first as dependency.

But, then again, I had some people suggesting this wasn't good enough (for deployment reasons, IIRC). I still use on my personal projects, though.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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/65aac79d-064f-4142-96e0-4f9592cd6862%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Julio Biason, Sofware Engineer

AZION  |  Deliver. Accelerate. Protect.

Office: +55 51 3083 8101  |  Mobile: +55 51 99907 0554

[Karol Bujaček]

Hello Andreas,

This issue bothers me too. For me, at the beginning it looks reasonable
to create two (or more) different apps, but sooner or later, I’ve
created a huge mess with too many dependencies between these apps. So,
sometimes I feel that separating whole application is not the best idea.
Obviously, there should be many lines of code which can/may/should be
shared (= reusable app), but I think that almost always I need to make
some customizations, add some ‘custom logic’ into views inside these
apps... I don’t know how to grasp Django’s architecture, I feel that I’m
missing something, that there should be something different than model &
view & template.

I've recently tried to read mentioned Two scoops of Django book, but it
doesn't help me with this. (Or I didn't spend too much time reading it).


Best regards,
Karol

[Mike Dewhirst]

For me, it is relatively easy. When you think of an entire project and
draw it out on paper with boxes and lines you can see where the separate
portions naturally fall.

Some things (nearly) always exist in (nearly) all projects. For example,
users and user related items like profiles. For me, that means a
separate app. Likewise (for me) I keep companies in a separate app.
Licensed relationships between companies (for me) also go in the company
app.

I don't necessarily try to make them re-usable right away. Working on my
second project I just copied portions of the first and tweaked them as
necessary. If that starts to bother me in future I might rework one or
two apps so they become re-usable and supremely elegant. Maybe.

The idea is to become comfortable putting "from company
importAddress,Company, Division, Phone" and just use them without
thinking in your views, unit tests or other portions of your project
where they might be needed. At least I don't have to scratch my head and
try to remember where Address is defined. Of course it belongs in the
company app alongside Phone and Division.

One of my projects has an enormous app with 40 models. I tried to
separate them into two apps but my inexperience caused circular import
problems. That forced me to keep them all together. In hindsight keeping
them together was the right thing to do because those 40 models are all
in the same brainspace.

I also have a "common" app to contain bits and pieces like utilities,
generic template tags, exceptions imported from various places so I can
always say in my code everywhere "from common.exceptions import
ThisErrorOrThat". My common app doesn't have any models.

The bottom line is that you need to be comfortable in your own
brainspace. If you can think about slicing off the easy bits into
separate small apps it will leave the main game slightly more simple.
And that is always good!

Cheers

Mike

[Derek]

Mike Dewhirst wrote:
I also have a "common" app to contain bits and pieces like utilities ...

I don't keep these under apps; my project-wide utility-type code (code without Django Models) sits under a "utils" module (with further namespaces as needed), at the same level as "apps"  This means it can be equally accessed by other utility code or apps themselves.  In terms of the project "design space" that makes more sense to me, and also allows utility code to be used across projects as I know there is no dependancy on projects-specific apps.

My 2c!