Блог

В настоящее время я разрабатываю свой собственный блог в 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 и описал в blog/models.py нем все модели, которые мне нужны для блога (User, Post, Comment и т.д.), Но потом я посмотрел 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 or main app , если хотите, которое использует все модели (django-apps) и в основном состоит из views.py . И я думаю, что теперь нам не нужно views.py все django-apps (хотя это под БОЛЬШИМ знаком вопроса — это только в теории).

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

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

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

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

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

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

Тогда вы готовы к выступлению Джеймса Беннетта о возобновляемых приложениях с DjangoCon 2008 (Слайды). Другой, более свежий взгляд на ту же тему — это подключаемые шаблоны приложений Django от PyCon 2011

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

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

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

Однако в любом приложении, более сложном, чем простой список дел, вы почти неизбежно столкнетесь с большим количеством пересечений. Нет единственно правильного ответа. Просто руководствуйтесь здравым смыслом и мыслите ТРЕЗВО (не повторяйтесь), и у вас все получится.

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

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

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

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

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

Мое субъективное мнение заключается в том, что приложения предназначены для повторного использования. Если они действительно пригодны для повторного использования, вы могли бы установить pip в свой следующий проект. Таким образом, в основном повторно используемые приложения должны быть отделены от вашей кодовой базы и в идеале на pypi.

Я просто использую одно приложение для каждого проекта и использую пакеты для разделения модулей.

например.

Перед

 journal/
  models.py
  

После

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

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