One app with many models vs. many apps with single model

I'm currently developing my own weblog in Django. But I've already stucked right in the beginning. So, here is my tree hierarchy:

/pyroot/nemoden/
|~blog/
| |-__init__.py
| |-admin.py
| |-models.py
| |-tests.py
| `-views.py
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|-manage.py
|-settings.py
`-urls.py

What I've done is: created new application called blog and described all the models I need for a blog in blog/models.py (User, Post, Comment, etc.), but then I watched Jeff Hui's video and realised that it is probably a bad idea and in Django-world people don't do that... what we do in... PHP-world using our PHP Frameworks. I guess it is better to have distinguished Django-applications for Tags, Comments, Users, etc...

So, what I'm asking is:

Is it better to have one model per Django-app? If so, are there some exceptions when I should not create a new Django-app for a model?

I want to go with:

/pyroot/nemoden/
|~blog/ # this is actual application (not a django-application). It uses all the models in views.py, so django-apps becomes just models
| |-__init__.py
| |-tests.py
| `-views.py # all the views (controllers in other frameworks) used by our (well,... my) weblog
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|~post/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-models.py # only Post model goes here
| `-views.py
|~tag/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-tag.py # only Tag model goes here
| `-views.py # <---- I don't know why we still need it here!
|-manage.py
|-settings.py
`-urls.py

As you see I cut out models.py and admin.py from blog app, so now blog app more like the app or main app if you wish which uses all the models (django-apps) and mainly consists of views.py. And I think now we don't need all views.py in all django-apps (this one is under a BIG question mark,开发者_如何转开发 though - it is just in theory).

Is my approach any good or I will suffer problems invisible for me now, maybe?

Is it better to have one model per Django-app?

One of the key ideas for a reusable application is: Do one thing, and do it well

If an app needs several models (PostEntry, PostAuthor in case of a Blog App) this is by no means bad. Tags, Categories, Comments however represent distinct features which ideally can be reused in another context and therefore should be distributed as standalone apps.

Is there best practices?

To get a feeling for a good app organization I'd first take look at Django Reusable App Conventions.

Then you are ready for James Bennett's talk about Resuable Apps from DjangoCon 2008 (Slides). Another, more recent take on the same subject is Pluggable Django Application Patterns from PyCon 2011

The rule of thumb is than an "app" should be a complete piece of functionality. If your blog cannot run without tags (like literally, not just it would be nicer to have a blog with tags than without) then tags should be part of the blog app.

However, there's no clear-cut answer here. Some app-purists focus entirely on re-usability and make each app a discrete piece of functionality with little to no dependencies on anything else. Some create entire applications with a single Django app. It's really up to you to decide what makes the most sense in your particular scenario.

In general, I would say combine functionality that won't likely be used else, but is required for the app, all in the same app. Things like tags or comments are probably candidates for their own apps, and indeed, you can find many such apps available that can be simply plugged into your app to provide that functionality.

In any app more complicated than a simple to-do list, you're pretty much inevitably going to end up with a good deal of crossover, though. There's no one right answer. Just use common sense and think DRY (don't repeat yourself) and you'll do okay.

I found this guy on youtube, that says he's dealt with this exact problem: both having a huge app and lots of little ones he considers to be not good.

http://youtu.be/URztqq1kiqI?t=22m39s

From my own experience: you don't want one big app, because people can handle better folder trees that are spread a little, but not too much. Also having one app would make harder to grasp what are the components of your project (for new people)

On the other hand, the more apps you have (that do depend on one another), the more chances you have to run into circular import problems. So you need a strategy for avoiding these things. Here also, newer members would tend to drive the project into problems.

All in all, people who've developed on more projects, for longer, should usually be the ones making architectural decisions.

My subjective view is that apps are meant to be reusable. If they are truly reusable you could pip install on your next project. So basically reusable apps should be separate from your codebase and ideally on pypi.

I just use one app per project and use packages to break up modules.

eg.

Before

journal/
  models.py

After

journal/
   models/  # All models share the same database namespace. In this case 'journal_'
      __init__.py
      auth.py
      page.py

Nemoden, your approach to change project tree is correct. You should divide your app into smaller functionalities as this will enable you to make your application more modular and code will be more reusable in the future.