Django and MVC(MVT) layout

Im coming from using other MVC based frameworks, and going into Django, it seems a little awkward to what im used to. For example, in other MVC based frameworks. my layout might be like so:

root:
- config (houses the config files (like settings), url.conf, db connections, etc.)
- controllers (houses the main logic of each section of the site. The middle ground between views and models)
- models (handles all the data to be validated and anything that interacts with the database. declares the DB structure. each model a class, each attribute a db field. in django, a template?)
- views (the html displayed to the end user, put together by the controllers)
- tests (all the tests)
- plugins (3rd party apps you install into yours.)
- uploads (user uploaded files)
- public_html (the actual public facing files)
-\ css|js|img (the various static file types for page manipulation)
-\ index.html

That is what im used to, and it seems like django does things very differently. Where before if I had a poll app i would have:

controllers/PollController.py
models/Poll.py
views/poll/index.py

and that would create the poll table in the db. But in Django, how would I do this? Is this an acceptable layout? From what I have read, the above would be more like this:

root:
- project (this would be the main app, and what glues everything together)
--/ settings.py
--/ urls.py
--/ templates/

- apps
-/ Poll
--/ models.py (i would have no Poll.py model, so it would all go in here)
--/ urls.py (any url.conf specific to this model would go in here)
--/ templates/ (the various views for this app)

while this does makes sense in some ways, it just feel alien to me. Is there any benefit to this type of layout over a traditional mvc layout described in the first example? Is there another preferred layout beyond this? The purp开发者_JS百科ose of this 'project' is that the core will be a basic framework for my own use and I have a few different 'apps' that i will create for each use of this framework. in the old version each application would just extend the main one by being a plugin in that directory.

As a background note, most of my experience is in php and the various frameworks from that worls (cakephp, yii, mostly), if that makes a difference. This will be my first main project in python/django. i just want to get it right.

The biggest benefit is that apps are modularized. You can remove your Poll application by deleting one directory instead of hunting through several directories deleting each piece. The flip side is if you found a Poll application somewhere that you wanted to use you can just drop in the one folder and you're good to go.

If you approach the idea of a site being a conglomeration of several individual and mostly distinct "apps" with some glue to hold them together then this organization makes much more sense.

Is there any benefit to this type of layout over a traditional mvc layout described in the first example?

Yes.

What you appear to be calling "Traditional MVC" is just another framework. It's not magically better or more right. It's just different.

Is there another preferred layout beyond this?

There are probably hundreds of ways to do this. Django chose one that fits nicely with Python and web applications.

i just want to get it right.

Then do this.

1. Discard your preconceptions left over from other things you've done.

2. Start fresh and empty with Django like a complete beginner.

3. After you've learned your 6th framework, you can then (and only then) compare and contrast the six frameworks you've learned. Until you've learned six, each one has to be taken as new, complete, different and unique.

Don't compare and contrast yet.

Just take Django as Django and do things the Django way.

(For more metaphorical advice, read about the music of Django Reinhardt; he had a unique view and a unique approach to the guitar.)

Notes

root # doesn't mean anything

• config -- Doesn't exist.

• controllers -- Doesn't exist.

• models -- A Python module with the class definitions for the persistent objects. Maps to RDBMS schema. Can have model-specific tests.

• views -- A Python module with view functions that respond to requests and create responses.

• test -- A Python module with View-specific and template-specific tests.

• plugins -- Doesn't exist.

• uploads -- Runtime, not development of the application.

• public_html -- Does not exist.

• css|js|img -- Static "Media" files. Runtime, not development.

• index.html -- Does not exist.

Stuff you omitted

• templates -- your HTML template pages, used by the view functions.

• admin -- admin bindings for the default admin site. Relies on modules and forms.

• forms -- form definitions; these are classes that produce forms used for input validation.

• urls -- mappings from URL paths to view functions.

• settings -- module with default database configuration, middleware, etc.