MVC в Django

Правильно ли я понимаю, что в джанге есть модель, представление (view) и шаблон для этого представления, но нет контроллера? То бишь контроллер заменяется view?

Верно.

MTV === MVC
Model === Model
Template === View
View === Controller

редставление (view) и шаблон для этого представления, но нет контроллера?

Ну да, можно сказать что view в джанге это контроллер.

Что есть app? Отдельный bundle?

да

Есть у меня скажем две сущности - пользователь и его посты. Работа с постами в одном app, а с пользователем в другом app?

Так можно сделать, но логичнее всё это делать в одном app.

Можно ли обращаться из одного app, к модели из другого?

Можно. Но лучше имхо разделать проект на приложения так, чтобы каждое приложение могло работать независимо от другого. Это в общем случае, часто бывает удобнее делать взаимодействие приложений.

Объясните пожалуйста «как правильно»? Как архитектурно верно строить web-приложение в Django.

Этого я не знаю =)

Так можно сделать, но логичнее всё это делать в одном app.

Если честно, еще не было ни одного случая, где для одного проекта нужно было использовать более одного app. А сами app, которые смогут быть использованы в разных приложениях писать как-то не удобно.

Считаю затею с app в джанге неудачной.

А я правильно понимаю, что views.py в приложении может быть не один? То есть, например, user_views.py, post_views.py. Верно?

Считаю затею с app в джанге неудачной.

Ну и зря. Я не профессионал, но и то юзаю django-app, вот например несколько штук, которые я использую в большинстве проектов -

https://github.com/dcramer/django-sphinx https://bitbucket.org/pi11/django-baner https://github.com/omab/django-social-auth https://bitbucket.org/pi11/django-email-auth - эту только недавно начал юзать.

Это не считая app из django.contrib.

Плюс еще в приватных репах несколько штук есть.

Так можно сделать, но я ни разу не видел, чтобы так делали. Да и зачем?

Не, в приложении только один views.py по дефолту, что может быть конечно не удобно, если в одном этом файле кучи кода.

Разделить можно следующими способами - или как у тебя:

сделать два файла user_views.py, post_views.py, а потом в urls.py импортировать с них нужные функции.

Либо создать директорию views в которой будут лежать все нужные представления и файл __init__.py, в котором имортировать все из представлений.

не было ни одного случая, где для одного проекта нужно было использовать более одного app

Магазины не писал что ли? Отдельное приложение - shop, отдельно приложение для работы со статьями, отдельное для заполнения кастомных страниц.

Если во views очень много кода, я бы лучше выделил сложную логику в отдельный пакет или разделил на app. Но это конечно вкусовщина.

ну ты можешь это как угодно организовать, views ведь может быть и модулем а не файлом ;)

Так, а как в целом принято? Я об этом и спрашиваю. Так сказать ищу best practice.

Так можно сделать, но я ни разу не видел, чтобы так делали. Да и зачем?

Ну, один контроллер для пользователей, другой для постов, и так далее.

Так сказать ищу best practice.

Лучше всего модулем, приятнее для глаз и логичнее.

З.ы. best practice: все сваливают на bottle + SQLA =)

Это в тебе говорит ROR. =)

Если честно, еще не было ни одного случая, где для одного проекта нужно было использовать более одного app

Это говорит только о размере ваших проектов, и не о чем более.

А сами app, которые смогут быть использованы в разных приложениях писать как-то не удобно

Криворукий архитектор детектид

Считаю затею с app в джанге неудачной.

И совершенно напрасно, потому что эта «неудачная» идея способна, при правильном подходе, сэкономить вам много-много часов на отлове ошибок в проектах больше чем страница-визитка. Модульный дизайн, он вообще-то именно для этого и существует.

делай как удоюно, делать вьювом модуль или файл это по сути одинаково, ресли у тебя цбв например то я бы делал модуль, а так то хрен знает, в большей мере зависит от масштабов проекта, наверное

В общем, сделал следующую структуру:

mylogin:~/WWW/proj-name/proj-name (master) $ tree
.
├── proj-name
│   ├── __init__.py
│   ├── __init__.pyc
│   ├── settings.py
│   ├── settings.pyc
│   ├── urls.py
│   ├── wsgi.py
│   └── wsgi.pyc
├── app
│   ├── __init__.py
│   ├── models.py
│   ├── static
│   │   ├── bootstrap
│   │   │   ├── css
│   │   │   │   ├── bootstrap.css
│   │   │   │   ├── bootstrap.min.css
│   │   │   │   ├── bootstrap-responsive.css
│   │   │   │   └── bootstrap-responsive.min.css
│   │   │   ├── img
│   │   │   │   ├── glyphicons-halflings.png
│   │   │   │   └── glyphicons-halflings-white.png
│   │   │   └── js
│   │   │       ├── bootstrap.js
│   │   │       └── bootstrap.min.js
│   │   └── css
│   │       └── main.css
│   ├── templates
│   │   ├── layout.html
│   │   └── phone_calls
│   │       └── list.html
│   ├── tests.py
│   └── views
│       ├── __init__.py
│       └── phone_calls_views.py
├── manage.py
└── static
    └── bootstrap
        ├── css
        │   ├── bootstrap.css
        │   ├── bootstrap.min.css
        │   ├── bootstrap-responsive.css
        │   └── bootstrap-responsive.min.css
        ├── img
        │   ├── glyphicons-halflings.png
        │   └── glyphicons-halflings-white.png
        └── js
            ├── bootstrap.js
            └── bootstrap.min.js

Судя по твоим вопросам, ты не понимаешь одну простую вещь. Приложения в джанге - это обычные питоновские модули. Можно ли в одном модуле использовать другой? Можно ли модуль разделить на два подмодуля? Ответы очевидны.

Static в корне -это от команды collectstatic? Если да, то лучше такое выносить из проекта отдельно.

Static в корне -это от команды collectstatic? Если да, то лучше такое выносить из проекта отдельно.

Почему?

Зачем держать файлы статики, которые собираются из всех подключенных приложений, в каталоге проекта? Конечно, никто не запрещает, но лучше сразу привыкать не держать такое в каталоге проекта.