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. On Sunday, March 8, 2015 at 9:56:51 PM UTC+3, Gabriel Klein wrote: > > 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. > > > -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1e837f28-285e-4754-bf5c-2b3ddb77e614%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
