где именно должна быть размещена бизнес-логика Python в Django

26

Я только начал изучать Django / Python / Web Development. Эта проблема беспокоила меня уже некоторое время.

Я создаю приложение с несколькими шаблонами в Django. У меня есть файл views.py, который в основном просто отображает ответы на соответствующие шаблоны, и у меня есть файл models.py, в котором я структурировал свою БД. В одном из моих шаблонов мне нужно загрузить изображение (что я могу сделать), и мне нужно запустить логику, основанную на функциях загруженного изображения (еще не сделано). Эта логика включает в себя много тяжелых вычислений. После выполнения вычислений логика должна вернуть некоторую обработанную информацию (координаты) в шаблон.

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

Я много занимался поиском, но до сих пор не могу понять, где именно я должен разместить этот файл Python, содержащий всю логику. Должен ли я иметь другой файл на основе классов (logic.py)и вызвать его из view.py? Я погуглил и обнаружил, что многие разработчики помещают свою бизнес-логику в свои models.py в Django. Тем не менее, я чувствую, что это интуитивно неправильно, поскольку модель должна общаться исключительно с бэкэндом Любая помощь будет оценена. Спасибо заранее.

adrita
источник
Возможный дубликат Где поместить бизнес-логику в дизайн MVC?
Барт ван Инген Шенау
Нашел статью, в которой широко обсуждается эта тема (с учетом пирамиды, а не django). Имеет несколько разумных умников: nando.oui.com.br/2014/04/01/…
Кратенко

Ответы:

16

Я много занимался поиском, но до сих пор не могу понять, где именно я должен разместить этот файл Python, содержащий всю логику.

Есть несколько вариантов, в зависимости от ваших требований:

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

  2. Добавьте логику как простой Imageкласс Python , например, в файле с именем image.py. Ничто в Django не ограничивает вас от добавления логики, кроме как в модулях viewsили models. Это хороший вариант, если логика изображения является центральным компонентом вашего приложения Django (например, приложения обработки изображений).

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

  4. Создайте отдельное приложение, которое обрабатывает запросы асинхронно и запускается отдельно от вашего приложения Django. Эта опция полезна, если вам необходимо отделить обработку изображений от цикла запроса приложения, обработать большое количество изображений или если каждый расчет занимает слишком много времени для решения в течение времени цикла запроса (скажем, в пределах не более 500 мс до 1 с) ,

Я чувствую, что это интуитивно неправильно, поскольку модель должна общаться исключительно с бэкэндом.

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

miraculixx
источник
Благодарность! Это было действительно проницательно. Я чувствую, что вариант № 3 должен быть достаточно хорош для меня. :)
Адрита
Оценить ответ отрицательно, но, пожалуйста, добавьте комментарий, чтобы я мог его улучшить
miraculixx
5

Даниэль Гринфельд, соавтор книги «Два совка Django», рекомендует, чтобы бизнес-логика должна быть в моделях », когда это возможно, или в формах, если необходимо. Что касается возможного дубликата Барта, django может быть похож на MVC, но это не MVC. Как объясняется здесь в официальной документации по django faq. @adrita, я думаю, что вам, возможно, потребуется изучить официальную документацию, чтобы немного лучше понять концепцию моделей, представлений и шаблонов.

Diek
источник
спасибо за ваши предложения. обязательно
пройдусь
Рад, что вы это исправили, @miraculixx дал убедительное объяснение. Если вы находитесь на fb, присоединяйтесь к группе фреймворка Python django.
Дик
2

В официальных документах Django https://docs.djangoproject.com/en/1.11/ говорится:

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

Джанго рекомендует, чтобы логика содержалась в представлениях.

Саймон
источник
3
Это не обязательно то же самое, что бизнес-логика.
FirstLastname
1
Я не согласен с такой интерпретацией документации Django. В другом месте в документации по Django (например, для Model.clean()) подразумевается немного более явно, что (если мы просто реализуем проект Django для моделей, шаблонов и представлений) - бизнес-логика (или, по крайней мере, проверка) принадлежит модельный слой. Обратите внимание, что я не включил формы в это упрощение, которые также являются приемлемыми.
Kye R