В MVC (например, Django), какое лучшее место, чтобы поместить вашу тяжелую логику?

Question

В архитектуре MVC рассмотрим django:

У меня есть метод вычисления лучшего сотрудника года (1000 строк кода со сложной логикой), где я должен его определить и кто будет его называть?

Спасибо

Answer 1

Из Джанго документов

Добавление дополнительных методов Менеджера предпочтительный способ добавить «уровень таблицы» функциональность для ваших моделей.

1. Создать модуль с такой логикой (year_employee.py)

2. Допустим, у вас есть модель Employee, поэтому вы должны создать класс для управления сотрудниками:

   class EmployeeManager(models.Manager)
       def of_the_year(self):
           from year_employee import my_calc_func
           return my_calc_func()
   

Затем добавьте этого менеджера в вашу модель

class Employee(models.Model):
    [...]
    objects = EmployeeManager()

После этого вы можете просто сделать это:

chosen_employee = Employee.objects.of_the_year()

Answer 2

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

С django FAQ :

В нашей интерпретации MVC «Просмотр» описывает данные, которые получают представленный пользователю. Это не обязательно, как выглядят данные, но какие данные представлены. Вид описывает, какие данные вы видите, а не как ты видишь это. Это тонкое различие.

Поместив вашу бизнес-логику в модели, вы упростите процесс модульного тестирования, поскольку модели не связаны с методами или обработкой HTTP.

Answer 3

1. установка логики в View не позволит Вы можете написать модульные тесты легко и не может эффективно использовать. Это говорит что вы никогда не должны ставить сложная логика в представлении вы должны отделить его от вида.
2. Если логика тесно связана с (класс / объекты класса) сдача эта логика в модели имеет смысл.
3. В случае, если логика тесно связана несколько объектов / классов, которые вы можете использовать одна из моделей, чтобы поставить логику или вы может создать объект службы (или когда код слишком велик), который будет обрабатывать эту логику.

Answer 4

Я согласен с теми, кто считает, что такую ​​логику следует размещать в файлах models.py. Однако что-то такое же большое, как у вас, с более чем 1 тыс. Строк кода, начнет загромождать файлы models.py [для меня]. Я был бы склонен переместить такой код в отдельный файл в рамках данного приложения. Ничего страшного в этом нет.

Answer 5

Это пользовательское приложение? Если да, то извлечение бизнес-логики из представления вряд ли будет вообще возможным. Иногда вы должны поместить это туда по множеству причин, одной из которых будет ремонтопригодность.

Помимо этого, расчет должен быть за пределами пользовательского интерфейса, в 99,9% случаев.

Answer 6

Я пытаюсь следовать концепции «тощий контроллер, толстая модель» (ссылка специфична для Rails, но концепция все еще применяется). В вашем контроллере вообще не должно быть много кода, кроме как для обработки сессий, файлов cookie, форм и т. Д. Вся логика вашего приложения должна находиться в вашей модели, что упрощает тестирование и рефакторинг позже.

Answer 7

Из ваших входов:

Определение отдельного модуля "services.py" для хранения методов / классов со сложным алгоритмом и логикой.

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

Спасибо за ваши ответы.

Answer 8

Что касается вашего конкретного примера, «метод вычисления лучшего сотрудника года (1000 строк кода со сложной логикой) ... где я должен его определить и кто будет его называть?»

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