Предыдущий мой пост к моему удивлению вызвал бурную реакцию. В нем я рассказывал как некоторые модули джанговского приложения можно разделить на более мелкие.
Общее настроение комментариев - это в большинстве случаев не нужно. Так я полностью с этим согласен. Я и не пропагандирую эти способы как ежедневные практики. Я лишь пытался показать как это можно сделать теоретически.
Да, концептуально необходимость дробления например models.py скорей всего признак каких-то ошибок в проектировании проекта и приложения. Ну а кто не ошибается?
Что все сразу знают как их предметную область разделить на приложения? Чтобы все они были по возможности изолированные и повторно используемые? Так более того в большинстве случаев это не нужно. В большинстве проектов есть всего одно приложение, где заключен весь его (проекта) функционал. В таких случаях и приходит на ум идея разделения распухших модулей на более мелкие.
Спрос есть - такие вопросы регулярно всплывают в рассылках и форумах. Плохо это или хорошо другой вопрос и не такой однозначный.
Я конечно понимаю, что джангисты перфекционисты по сути (да я и сам такой), но не бывает идеального кода, архитектуры и вообще чего угодно. И как раз проекты, которые "работают" в большинстве своём внутри далеко не пример для подражания. Это баланс. Проектировать всю жизнь и ничего не сделать в итоге ещё хуже, чем где-то что-то не отполировать до блеска, но заставить "работать".
Так что если вдруг вам понадобилось какое-то не очень красивое решение, это не значит, что если вы его сделаете, то вас ждет кара небесная. Нет, это лишь говорит о том, что ваш список рефакторингов увеличился на один пункт. А время его разгребать придет не сейчас и это хорошо.
PS: Хотел написать про то как шаблонные теги держать вне templatetags, но передумал...
Комментарии 6
Забей! Стаьтя была хорошая и решение тоже отличное. Я, например, взял себе этот метод на заметку, спасибо.
А фанатики найдутся всегда, но надо понимать, что ко всему надо подходить с умом... что в этом способе, что в использовании, например, операторов безусловного перехода, да и вообще везде.
Оставлен 24 Апрель 2009 в 18:16 ¶Я тут внезапно свои 5 копеек вставлю. Так вот, человечество изобрело такой этап разработки как проектирование, на котором можно проанализировать предметную область и определить будущий функционал и разделение на приложение и модули. Пропуск этого этапа, мне кажется, признак некомпетентности или спешки. Остальное - от лукавого.
Оставлен 24 Апрель 2009 в 22:39 ¶поддерживаю идею о рабочем и не красивом, чем не рабочем и в проекте ;)
да и вообще, иногда реально необходимо раздробить
Оставлен 25 Апрель 2009 в 00:36 ¶models.pyна более мелкие куски ибо просто не хочется оперировать например 200-строковым файлом, когда можно оперировать двумя 100-строковыми файлами. вотУтверждаю, что сам этап проектирования в большинстве случаев сам от лукавого.
Мы же перфекционисты, но с дедлайнами. Так вот они и заставляют быстро писать прототипы и смотреть "как оно живет" не теоретически, а на практике. Во многом за это мы и любим питон с джангой.
Проектирование штука хорошая, но это опять, возвращаясь к вопросу баланса, главное не увлекаться и делать продукт с какими-то допусками по качеству, а не фанатеть от рисования диаграмм и прочих артефактов.
Оставлен 25 Апрель 2009 в 09:20 ¶я хочу сказать, что иногда бывают проекты, когда задачи очень быстро меняются.. не всегда вначале можно спроектировать всю систему, увы.
Оставлен 25 Апрель 2009 в 10:34 ¶Однозначно, статья полезная была. Я, например, на симфоне писал, перед тем как столкнулся с джангой. И для меня дикостю было в одном файле несколько моделей. И соответственно были попытки найти это решение...
Статью тоже взял на заметку, но разделять - не разделял еще и пока что не собираюсь. Нет необходимости.
Оставлен 22 Май 2009 в 09:16 ¶Оставьте комментарий