Организация кода Django

Я недавно начал работать с Django. Я работаю над существующим сайтом на основе Django/Python. В частности, я реализую некоторые функции для создания и отображения PDF-документа при ударе определенного URL-адреса. У меня есть запись в файле URL-адресов приложения, который направляется к функции в файле представлений, а генерация PDF работает нормально.Организация кода Django

Однако функция просмотра довольно большая, и я хочу извлечь код где-нибудь, чтобы мой взгляд был как можно более тонким, но я не уверен в лучшем/правильном подходе. Возможно, мне нужно будет сгенерировать другие PDF-файлы со временем, так что было бы целесообразно создать приложение «pdfs» и разместить там код? Если да, то следует ли в модели или в представлении?

В среде PHP/CodeIgniter, например, я бы поместил код в модель, но модели, похоже, тесно связаны с таблицами базы данных в Django, и для этого мне не нужны никакие функциональные возможности.

Любые указатели/советы от более опытных пользователей Django будут оценены по достоинству.

Благодаря

источник

2015-08-15 Nick Roper

Модель должна использоваться только для базы данных. Трудная работа должна быть сделана с точки зрения. Хорошей практикой является создание одного приложения для каждой задачи. Если у вас есть только одна задача (создание pdf), и ваше представление все еще слишком велико, вы можете просто создать файл create_pdf.py и выполнить там тяжелую работу. –

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

Да представлениями являются контроллеры. Я стараюсь вставить как можно больше функциональности в модели, чтобы обойти «несоответствие объектно-реляционного импеданса» – Pynchia

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

В качестве первого шага просто поместите его в отдельный класс и выполните этот код из представления. В какой-то момент вы, вероятно, захотите сделать некоторые проверки разрешений и т. Д., Которые остаются в представлении, в то время как генерация самого PDF будет чисто разделена.

После того, как вы проверите свой код, масштаб и т. Д., Вы можете подставить этот однолинейный вызов в представлении, поставив его в очередь, и только потянув его, как только это будет сделано - это позволит вам управлять своими вычислительными возможностями лучше.

источник

2015-08-15 07:58:18

Привет, спасибо за большой совет :-) Я должен был уточнить - я использую только URL-адрес браузера во время тестирования.В процессе производства PDF будет генерироваться только (и затем прикрепляется к электронной почте), когда кто-то покупает услугу через сайт, поэтому функциональность будет вызвана обратным вызовом из платежного шлюза, и не будет публичного URL-адреса, который может получить удар по трафику. –

В этом случае производительность не должна быть проблемой. На самом деле, один из разработчиков ядра django однажды сказал мне, что, как правило, если что-то занимает более 10-15 строк, и есть способ его абстрагировать, вы должны. Возможно, в некоторых случаях это немного экстремально, но я всегда помню это сейчас. –

Мне нравятся идеи по масштабированию - и бизнес растет, там будут другие PDF-файлы для создания, поэтому отдельное приложение имеет смысл. Кроме того, создание поколений и электронных писем было бы хорошей идеей, тогда их можно было бы запустить на работу cron и оказать минимальное влияние на веб-сервер - приятно подумать, спасибо. –

Да, вы можете в принципе сделать это в приложении (концепция многократного использования приложений является основой для их существования)

Однако не многие люди делают это/не многие приложения требуют его. Это зависит от того, как/если функциональность будет использоваться совместно. Другими словами, должна быть реальная выгода.

Код обычно идет как в представлении/с и в моделях (изолировать код и для менеджеров модели)

источник

2015-08-15 06:13:50 Pynchia

Спасибо, так что, возможно, альтернатива, как было предложено выше, - извлечь код в отдельный файл create_pdf.py, который Я предполагаю, что мне нужно будет импортировать в основной файл представления? –

Это правильно – Pynchia

И будет ли этот отдельный файл рассматриваться как подвид или что-то в этом роде? –

Организация кода Django

ответ

Смежные вопросы