M
ну смотри, если бы я знал как вынести бизнеслогику от кода, то и вопроса по организации небыло, но энивей спасибо что помог оформить дыру в знаниях.
Size: a a a
2019 February 28
pk
тода у тебя фактически схема взаимодействия "юзер запросил продажи по товару за дату". запрос принимает джанга. формирует этот запрос на сервис layer. там реализована бизнеслогика сбора данны, и результат отдается в осгласованном формате обратно во вьюху, где она уже передается на морду
M
а сервис леер по идее не должен дерагать базу, или должен?
pk
чойта не должен?
pk
просто разные зоны ответственности
pk
для юзеров джанга юзает свой ОРМ. а для не связанных с джангой данных (продажи те же) - это уже своя логика сбора данных. и сервис сбора сам уже ходит в базу
pk
возможно даже в не ту же куда ходит джанга
M
да кстати, зачем пилить одельные энтити если по сути модель и есть энтити?
pk
M
есть entity и value objects
M
я о них
M
о я из англии
pk
не хочу углубляться в вопрос. мой ответ "хз"
pk
не очень понимаю о чем ты. и лень вникать =)
M
ладн. :)
A
Пользователь может загрузить экспортированный отчёт (xml, xls) и работать с ним, редактировать данные.
Загрузил файл в память, вытащил данные сохранил в своём формате, файл выкинул
A
Maksimgeolog
ну смотри, если бы я знал как вынести бизнеслогику от кода, то и вопроса по организации небыло, но энивей спасибо что помог оформить дыру в знаниях.
Сделай прослойку между моделями и вьюхами назовём это service layer, результат модели не пухнут, код можно использовать в разных вьюхах, они не пухнут
M
да ее организовть не проблема, но где гарантия что я не превращу ее в гавно?
M
там же свои нюансы разжделения
M
одно дела в слепуюстроить, другое дело пониматьна что сразу стоит обращать внимание