Clarifying Project vs Apps

[Rich Shepard]

While I think that I understand the differences between a project and its
apps there remains one point of uncertainty. I've not found the answer,
although it might be in the 1.10 docs or on the Web and I've missed it.

If the project represents the entire database, do the apps represent
individual tables? That is, should my project have a separate app for each
table with its models, templates, and views with templates of joined tables
in the main project subdirectory? Or are all tables in a single app?

TIA,

Rich

[Lee Hinde]

My tuppence.. No, an app is a logical grouping of objects/tables. You might, for instance,have an Invoice app that would include an Invoice table (model) and a LineItems table. Products and related tables would be in a different app.

[Rich Shepard]

On Wed, 24 Aug 2016, Lee Hinde wrote:

> My tuppence.

Lee,

Before or after Brexit? The value might change. :-)

> No, an app is a logical grouping of objects/tables. You might, for
> instance,have an Invoice app that would include an Invoice table (model)
> and a LineItems table. Products and related tables would be in a different
> app.

OK, that makes sense.

In my current project, then, all modules for company, contact, activity,
case, etc. will be in a single app. And, perhaps, another app would be for
reporting?

Translating from product-oriented applications to service-oriented ones is
not always easy.

Thanks very much,

Rich

[Lee Hinde]

So, no one is going to grade it. You're making this for yourself, so I wouldn't over think it. I'm working on a project now that only has two apps, one with all the core models and one for utility models (like choice lists).(I'm using several packages, so the database has more to it than that.) 

It sounds like something like that would work for you and still be 'right'. Especially as a first time out of the gate project, keep it simple. IMHO.

While it will certainly evolve as you use it, you're not gong to suddenly wake up and need 18 more apps to meet your needs. And if that does happen, you can rearrange. 

[Andreas Kuhne]

--
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/CA%2BePoMwf38zOGytfpoQc49pdSuxLyw-zqEdaRcqcjhJE3dV4VA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

If you know how your project will be used, you can usually group the models and views in logical apps. For example a customer app that has the customer (user) model, address model. Then another app for orders and invoices and so on.

The only thing you have to make sure is that the grouping makes sense for you. You can also check out different design patterns that can help you design your application, but you are usually the one who knows the application best.

Regards,

Andréas

[Rich Shepard]

On Wed, 24 Aug 2016, Lee Hinde wrote:

> So, no one is going to grade it. You're making this for yourself, so I
> wouldn't over think it. I'm working on a project now that only has two
> apps, one with all the core models and one for utility models (like choice
> lists).(I'm using several packages, so the database has more to it than
> that.)

> It sounds like something like that would work for you and still be 'right'.
> Especially as a first time out of the gate project, keep it simple. IMHO.

Lee,

Now this is a valuable lesson: core models and utility models. Many of my
classes have choice lists (select from a list of industries, or campaign
types) so I'll put those in the models.py of a separate app.

> While it will certainly evolve as you use it, you're not gong to suddenly
> wake up and need 18 more apps to meet your needs. And if that does happen,
> you can rearrange.

No, not on this project. But the next one will require more apps because
it has more functional groupings.

Many thanks again,

Rich

[Rich Shepard]

On Wed, 24 Aug 2016, Andreas Kuhne wrote:

> If you know how your project will be used, you can usually group the models
> and views in logical apps. For example a customer app that has the customer
> (user) model, address model. Then another app for orders and invoices and
> so on.

Andréas,

Here you've given me an alternative approach for my application slightly
different from Lee's way of presenting it. Much to think about before I
proceed.

Much appreciated,

Rich

[Andromeda Yelton]

My feeling/practice on apps is: each app is a one-word informative noun. It contains the models that are logically grouped under that noun (and the views, urls, etc required to interact with those models on the front end).

If there isn't a single word that logically represents all my models, then they need to be separated into multiple apps. (And if models.py has gotten long enough that it's unwieldy, it probably wants to be split.)

So, e.g., "companies" or "invoices" or "customers" or "reports" are all perfectly decent app concepts.

Also, _Two Scoops of Django_ is a helpful book for developing Django best practice intuitions.

--

Andromeda Yelton

Vice President/President-Elect, Library & Information Technology Association: http://www.lita.org

http://andromedayelton.com

@ThatAndromeda

[Andreas Kuhne]

--

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/CAFE1XCbixOV-66k-RwCYHb9io0UCyZ%2BJZx0asFvRiZWXioDL5A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

That's exactly what I would like to do as well. I am also trying to get my head around micro-services, and try to create apps that can be exchanged by micro-services. But I'm not there yet :-)

Regards,

Andréas

[Rich Shepard]

On Wed, 24 Aug 2016, Andromeda Yelton wrote:

> My feeling/practice on apps is: each app is a one-word informative noun.
> It contains the models that are logically grouped under that noun (and the
> views, urls, etc required to interact with those models on the front end).

Andromeda,

So are table names.

> If there isn't a single word that logically represents all my models, then
> they need to be separated into multiple apps. (And if models.py has gotten
> long enough that it's unwieldy, it probably wants to be split.)
>
> So, e.g., "companies" or "invoices" or "customers" or "reports" are all
> perfectly decent app concepts.

Got it, thanks.

> Also, _Two Scoops of Django_ is a helpful book for developing Django best
> practice intuitions.

I have the one from django-1.5; the latest is for -1.8. Since the current
version is 1.10 I see no reason to get a newer, but still two versions
behind, copy.

Thanks very much,

Rich