Wednesday, February 28, 2018

Re: When do I need a new app within the site?

On 1/03/2018 4:46 AM, Karol Bujaček wrote:
>
>
> On 02/22/2018 09:44 AM, Cictani wrote:
>> 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
>>
>
> 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
>
>

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

--
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-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/5c813349-89d9-9b39-1cb0-0179d934562a%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment