Django structure

[Gabriel Klein]

Hi there,

I'm going to start a big project using Django.

It will have 3 main sections: 

- A "Frontend" section:

Where the user will consult the data.

- A "Backend" section:

Where the ETL and Admins will organize the data

- A User Management section:

Where I'll manage user permission, Oauth for my APIs

I'm aware that Django recommend to break down your project into a multitude of apps with a very small scope.

While my User Management section should be simple enough to be on his own app my two other sections "Frontend" and "Backend" come with a fairly complex snowflake schema (about 15 tables) and sometime with cross dependencies between apps. They also come with complex business logic that can be break down to smaller apps.

My question is how to shared models across apps? 

I was thinking creating a app only to cary my complex models?

This app can be now reuse within smaller app doing backend or fronted jobs.

Any advice will be welcome.

[Ilya Kazakevich]

There are 2 types of Apps in Django: 

1) reusable one with clear, documented interface

2) not reusable one, because it depends on current project heavily.

Ideally, project consists of several reusable-apps, and project-specific data is stored in project-specific places like URLConf or filesystem templates.

But in real life, project may have one or more non-reusable app tied to this project heavily. If you have app with specific business-logic you do not want to share it. If you have app with generic logic (forum, shop, email system, template engine, orm system, new field type, a pack of tags etc) -- you need to make it shareable. 

It is like modules in python: you have reusable packages and modules, but you almost always have "yourfile.py" script which is not reusable. But you should do your best to make this file as small as possible by making most of your code reusable and moving it to sharable packages and modules.

Actually, this is not only about Python: in OSes you have execution binary and .so files (if you are *nix user) or .exe file and .dll files (if you are windows user).

.so/.dlls are reusable, but .exe (or executable) is not. 

I think you should start with 4 apps:

1) user management

2) business logic (models and other staff used both in front-end and back-end)

3) front-end with front-end specific code

4) backend with back-end specific.

Back and front may depend on business, but not on each other, and business does not depend on anything.

You should be able to throw backend away, and totaly rewrite it, and be sure front-end and business logic is not affected.

Speaking in MVC term here, your business is Model, and Front and Back are both views. You may even need to create some new view, like portal which is not frontend nor backend,

You then try to fetch some "generic" parts from you apps. For example you may find that you use views/templates/tags to display some business data in fancy way. You may move it to business-logic part, to share between front-end and back-end.

Or you may find that you just created, say, email blast engine, or report engine, that can be used even with out of your business logic, in totaly different project! You then move it to separate app, and make it public to reuse in other projects.

Splitting code into modules (units, packages) is one of the hardiest things in software architecutre. It is ok to refactor existing projects changing modules structure, because you never know if your layout is good until you try to support such project. 

Ilya.

[Gabriel Klein]

Thank you Ilya,

What you said make a lot of senses. 

[Raphael Michel]

Hi,

I'll leave it to others to give recommendations on how you SHOULD
organizer your project. However, I can help you with the technical
question.

Am Sun, 8 Mar 2015 11:53:09 -0700 (PDT)
schrieb Gabriel Klein <gabriel....@gmail.com>:

> My question is how to shared models across apps?

You can use models across apps without any problems, just as you would
inside the same app:

from otherapp.models import MyModel

Raphael