МВ
Ну и тестировать легче
Size: a a a
2020 October 22
I
Смотрите - V значит View -то что мы показываем пользователю. M - model представление данных в базе. C - controller в который нельзя пихать логику. Где она тогда должна быть?😈
M - это не только прослойка между бд и приложением. Это бизнес-логика
МВ
Ну и вообще понять легче
МВ
Я бы не клал в модели какую либо логику не касающуюся связей сущностей
МВ
Это быстро выходит из под контроля
S
Просто суть то не в том чтоб не класть в контроллер или модель логику
Я просто сколько не виджел со стороны разборки - именно это и обсуждалось, что туда класть сюда, сюда нельзя и методом исключения остается контроллер. Но кто нибудь обязательно скажет - ТУДА НЕЛЬЗЯ ОН НЕ ДЛЯ ЭТОГО! 😃
I
В M также входят не только activerecord модели, но и сервисы, form object и тд
I
Имхо, конечно)
МВ
В M также входят не только activerecord модели, но и сервисы, form object и тд
Ну хранить их лучше в тдеьных классах
МВ
Иначе слишком много ответственности
МВ
А значит сложнее править
I
Ну хранить их лучше в тдеьных классах
Ну я ведь и говорю о сервисах и тому подобное
МВ
Ну да, согласен
S
В M также входят не только activerecord модели, но и сервисы, form object и тд
Ну то есть М - представление информации а не операции над ней
I
А не только о activerecord модели
IN
Так они и так
а ты видел гем файл этого Hey - там чисто легаси
IN
В классах
а контроллер это не класс?)
МВ
а контроллер это не класс?)
Ну это на самом деле спорный момент почему то у меня в голове
IN
Смотрите - V значит View -то что мы показываем пользователю. M - model представление данных в базе. C - controller в который нельзя пихать логику. Где она тогда должна быть?😈
Если следовать первой букве SOLID то у опредлеенной логики должна быть едиснтвенная ответвенность
МВ
Но если по делу то класс, но суть моей мысли в том чтоб разбивать логику на максимально атомарные классы по смыслу