Подтвердить что ты не робот

Джанго. Одно приложение со многими моделями и многими приложениями с одной моделью

В настоящее время я разрабатываю свой собственный блог в Django. Но я уже застрял в самом начале. Итак, вот моя иерархия дерева:

/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

Я сделал следующее: создал новое приложение, названное блогом, и описал все модели, которые мне нужны для блога в blog/models.py (Пользователь, Почта, Комментарий и т.д.), но затем я смотрел Jeff Hui's и понял, что это, вероятно, плохая идея, а в Django-world люди этого не делают... что мы делаем в... PHP-world, используя наши PHP Frameworks. Я думаю, лучше отличать Django-приложения для тегов, комментариев, пользователей и т.д.

Итак, я спрашиваю:

Лучше ли иметь одну модель для Django-приложения? Если да, есть ли исключения, когда я не должен создавать новое Django-приложение для модели?

Я хочу пойти с:

/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

Как вы видите, я отключил models.py и admin.py из blog приложения, поэтому теперь blog больше нравится the app или main app, если вы хотите использовать все модели (django-apps) и в основном состоят из views.py. И я думаю, что теперь нам не нужно все views.py во всех django-apps (этот под знаком BIG вопросительный знак, хотя - это просто в теории).

Мой подход хороший, или я буду испытывать проблемы, невидимые для меня сейчас, может быть?

Извините, если мой вопрос недостаточно ясен, если да, пожалуйста, прокомментируйте это ниже, я отредактирую его, чтобы он был более понятным.

Есть ли лучшие практики?

Спасибо.

4b9b3361

Ответ 1

Лучше ли иметь одну модель за Django-приложение?

Одна из ключевых идей для многоразового приложения: Сделайте одно и сделайте это хорошо

Если для приложения требуется несколько моделей (PostEntry, PostAuthor в случае приложения для блога), это отнюдь не плохо. Теги, категории, комментарии, однако, представляют собой различные функции, которые в идеале могут быть повторно использованы в другом контексте и поэтому должны распространяться как автономные приложения.

Есть ли лучшие практики?

Чтобы получить представление о хорошей организации приложений, я сначала рассмотрю соглашения об использовании Django для многократного использования.

Затем вы готовы к тому, что Джеймс Беннетт расскажет о Resaable Apps из DjangoCon 2008 (Слайды). Другой, более поздний подход к тому же вопросу - Pluggable Django Application Patterns от PyCon 2011

Ответ 2

Эмпирическое правило, чем "приложение", должно быть полной функциональностью. Если ваш блог не может работать без тегов (например, буквально, не только было бы лучше иметь блог с тегами, чем без него), тогда теги должны быть частью приложения для блога.

Однако здесь нет четкого ответа. Некоторые приложения-пуристы полностью сосредоточены на повторном использовании и делают каждое приложение дискретным элементом функциональности, практически не зависимым от чего-либо еще. Некоторые создают целые приложения с помощью одного приложения Django. Это действительно зависит от вас, чтобы решить, что наиболее важно в вашем конкретном сценарии.

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

В любом приложении, более сложном, чем простой список дел, вы в значительной степени неизбежно собираетесь получить много кроссовера. Там нет правильного ответа. Просто используйте здравый смысл и подумайте СУХОЙ (не повторяйся), и все будет хорошо.

Ответ 3

Я нашел этого парня на youtube, который говорит, что он имел дело с этой точной проблемой: оба имеют огромное приложение и много маленьких, которые он считает нехорошими.

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

Из моего собственного опыта: вам не нужно одно большое приложение, потому что люди могут обрабатывать лучшие деревья папок, которые немного распространяются, но не слишком много. Кроме того, наличие одного приложения затруднило бы понять, какие компоненты вашего проекта (для новых пользователей)

С другой стороны, чем больше у вас приложений (которые зависят друг от друга), тем больше шансов, что вам придется столкнуться с проблемами циклического импорта. Поэтому вам нужна стратегия для избежания этих вещей. Здесь также более новые участники будут склонять проект к проблемам.

В целом, люди, которые разработали больше проектов, дольше, обычно должны принимать архитектурные решения.

Ответ 4

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