В MVC (например, Django), что лучшее место должно поместить Вашу тяжелую логику?
Тип q: для вхождения в режим редактирования истории в новом буфере. Тогда отредактируйте последнюю строку буфера и нажмите Enter для выполнения его.
8 ответов
Добавление дополнительных методов Менеджера предпочтительный способ добавить "на уровне таблицы" функциональность ваших моделей.
- Создайте модуль с этой логикой (
year_employee.py) Допустим, у вас есть модель
Сотрудник, поэтому вам следует создать класс для управления сотрудники:класс EmployeeManager (models.Manager) def of_the_year (сам): from year_employee import my_calc_func вернуть my_calc_func ()
Затем добавьте этот менеджер в свою модель
class Employee(models.Model):
[...]
objects = EmployeeManager()
После этого вы можете просто сделать это:
chosen_employee = Employee.objects.of_the_year()
Что касается django, лучшее место для размещения бизнес-логики - внутри моделей. Представление должно быть чистым от бизнес-логики и должно использоваться только для отображения / представления данных в шаблоне или, другими словами, позволять использовать представление только для логики представления.
Из FAQ по django :
В нашей интерпретации MVC «Представление» описывает данные, которые получают представлен пользователю. Это не обязательно как данные выглядят, но какие данные представлены. Вид описывает, какие данные вы видите, а не как ты видишь это. Это тонкое различие.
Помещение бизнес-логики в модели облегчит вам модульное тестирование, поскольку модели не связаны с методами или обработкой HTTP.
Я согласен с теми, кто считает, что такая логика должна быть помещена в файлы models.py. Однако что-то столь же большое, как то, что у вас есть, с более чем 1 КБ строк кода, начало захламлять файлы models.py [для меня]. Я был бы склонен переместить такой код в отдельный файл в рамках данного приложения. В этом нет вреда.
- размещение логики в представлении не позволит вы можете легко писать модульные тесты и нельзя эффективно использовать повторно. что вы никогда не должны ставить сложная логика в представлении вы должны отделить его от представления.
- Если логика тесно связана с (класс / объекты класса) положить эта логика в модели имеет смысл.
- В случае, если логика тесно связана несколько объектов / классов, которые вы можете использовать одна из моделей поставить логику или ты может создать служебный объект (или когда код слишком велик), который будет обрабатывать эту логику.
Это пользовательское приложение? Если да, то извлечение бизнес-логики из представления на самом деле будет невозможно. Иногда вам приходится вставлять его туда по множеству причин, одна из которых - ремонтопригодность.
Помимо этого, в 99,9% случаев вычисления должны производиться за пределами пользовательского интерфейса.
Что касается вашего конкретного примера «метод расчета лучшего сотрудника года (1000 строк кода со сложной логикой) ... где я должен его определить и кто его вызовет? "
Для такого количества кода я, вероятно, создал бы новый модуль (возможно, rank.py) и поместил бы его туда. Кто его вызовет, зависит от того, как вы его используете, но я предполагаю, что он будет вызываться из одного из ваших представлений.
По вашим данным:
Определение отдельного модуля "services.py" для хранения методов / классов со сложным алгоритмом и логикой.
Как мы знаем, в конечном итоге вызов будет осуществляться из представлений (кто знает, чего он хочет), поэтому лучшее, что мы можем сделать, - это вызвать метод в моделях, который внутренне вызывает логику из модуля служб, использует данные моделей для выполнения обработки и возвращает результат для записи в ответ.
Спасибо за ответы.
Я стараюсь следовать концепции «тощий контроллер, толстая модель» (ссылка относится к Rails, но эта концепция все еще применима). В вашем контроллере вообще не должно быть большого количества кода, за исключением работы с сеансами, файлами cookie, формами и т. Д. Вся фактическая логика вашего приложения должна находиться в вашей модели, что упростит тестирование и рефакторинг в дальнейшем.