Где в Django хранить бизнес логику системы?

Question

[Bakotiinii]

Во многих PHP/Java/.Net фреймворках есть такой объект, как сервис - он позволяет подтягивать модели и производить с ними какую-то бизнес-обработку. И фактически весь код - это вьюха - прослойка из сервисов (сами сервисы дергают CRUD логику моделей) - вьюха.

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

Правильно ли я понимаю, что это наиболее эффективный способ организации кода?

P.s. я уже смотрел вопрос - Логика в моделях или во вью в Django?

Comments

[Roman K]

Логика в Контроллерах

Чиво? Логика в контроллерах? Сожги проект, в котором у тебя логика в контроллерах

Answer 1

[Сергей Горностаев]

Во-первых, best practice для Django - это fat models / thin controllers. Во-вторых, ничто не мешает вам сформировать сервисный слой, отделив прикладную логику в отдельные модули, независимые от фреймворка.

Comments

[Евгений Ромашкан]

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

[Сергей Горностаев]

Евгений Ромашкан, это фразеологизм.

Answer 2

[Дмитрий Свиридов]

Не надо fat models, делай сервисный слой. Эта либа пригодится. Правда при ее использовании твоя бизнес-логика все равно будет зависеть от Django, но все равно удобно))

Answer 3

[asd111]

Делаю как в других фреймворка. Логика в файлах service, в моделях только модель, во вьюхах дергаю только сервисы или привязку сервиса к шаблону.
На мой взгляд это самый каноничный подход, т.к. не важно какой у тебя фреймворк и язык - архитектура одинаковая и это удобно.
В Джанго ещё некоторые любят писать логику в class based views и потом мучаются т.к. не могут проследить логику и последовательность выполнения кода. Даже авторы Джанго когда использовали class based views наделали кучу дыр в безопасности, т.к. логика в этих файлах описывается непоследовательно.

Comments

[Евгений Ромашкан]

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

И какая разница какую архитектуру делать "одинаково"?

Не говоря уже о том что делать архитектуру везде одинаково в принципе глупая затея.

Лишь бы ляпнуть что...

[asd111]

Евгений Ромашкан, ну например когда пишешь на двух языках то удобно не думать почему в джанго весь код в модели если в го весь код был в сервисе.
Расслабься, я не призываю тебя писать код в сервисах, просто почти во всех веб языках теперь делают так. И мне так больше нравится.
Да и в том же Джанго с 2017 года best practices это не толстые модели а django service objects. А class based views назвали ошибкой сами core разработчики Джанго.

[Евгений Ромашкан]

asd111, Язык не влияет на то где логику писать

[asd111]

Евгений Ромашкан, этот вопрос как бы и возник из за того что в Джанго и в python фреймворках в целом логику пишут в разных местах, хотя в том же c# и java все пишут сервисы, а ты говоришь язык не влияет...
Лишь бы ляпнуть что...

[Евгений Ромашкан]

asd111, Пытаетесь притвориться что разбираетесь в теме, наслушавшись инфы из каких-то сомнительных источников?)

Не на джаве ли пишет Дядя Боб, не на Джаве ли Фаулер писал, не на Шарпе ли Уди пишет?

Не из Шарпа ли в мир хайп по ddd пришёл?

[asd111]

Евгений Ромашкан, ты обкуренный ? Что ты несешь...

[Евгений Ромашкан]

asd111, То есть вы даже имена такие не знаете.. Ясно.
Не то чтобы я особо сомневался, но теперь точно уверен что по теме вы даже Гуглом не воспользовались ни разу, зато других учить лезете )

P.s. Это люди которые задумываются о том как правильно писать код, вам тоже советую у них поучиться)