Это ещё ладно, у меня на работе в проекте контроллеры со всей логикой, там прямо в них инжектится uow и совершается вся работа вплоть до чтения или записи бд. Там методы вместе с приватными могут в сумме могут составлять сотни строк кода. Все борюсь с этим, топлю за то чтобы создавать слой бизнес логики, чтобы в контроллерах оставлять только try-catch, обращение к сервису и возврат результата.
А зачем все время пытаться отнести какую то часть кода к какой-то части MVC? У тебя есть набор каких-то классов, например services или interactors и ты четко определяешь зону их отвественности
затем, чтобы не допускать размазывания логики обработки запроса, например, которая принадлежит контроллеру и не сможет полностью переехать в сервисы. Кроме этого, это грязный уровень и смешивание его с бизнес-логикой затрудняет тестирование. В конкретных случаях это может пока не доставлять проблем. Например, итог данного рефакторинга - волне поддерживаемый. Нарушать можно, просто нужно понимать, что именно ты нарушаешь, чтобы понять, как потом улучшать
затем, чтобы не допускать размазывания логики обработки запроса, например, которая принадлежит контроллеру и не сможет полностью переехать в сервисы. Кроме этого, это грязный уровень и смешивание его с бизнес-логикой затрудняет тестирование. В конкретных случаях это может пока не доставлять проблем. Например, итог данного рефакторинга - волне поддерживаемый. Нарушать можно, просто нужно понимать, что именно ты нарушаешь, чтобы понять, как потом улучшать
@@SergeiUdalov Так ты и не будешь допускать протекания. У контроллера своя ответственность, у интерактора своя, у презенетера своя и т.д. Не достаточно ли определить ответственности и не завязываться на MVC?
@@IvanRudskikh если мы в интеракторе оперируем объектом params, то к нам протечет логика обработка и подготовки параметров. В интеракторы стоит передавать уже типизированные, валидированные по схеме параметры.
@@Deletedeletedelete Всё хорошо в меру. Если стремиться к чистоте без всякой меры, можно превратиться в душного коллегу, который саботирует работу, отказываясь аппрувить PR, если он не соответствует его извращённым представлениям о качественном коде.
![เปิด อาณาจักร หมื่นล้าน "สาระตั้ม" l [Nickynachat]](http://i.ytimg.com/vi/3XE0nPF4YkQ/mqdefault.jpg)
![[LIVE] BABYMONSTER(베이비몬스터) - DRIP | 두시탈출 컬투쇼](http://i.ytimg.com/vi/UG05pxLGwzc/mqdefault.jpg)
Контент пушка, я кайфанул. Особенно показ эволюции кода в диффе
@@RubyToTheCore какой вариант тебе больше всего понравился?
И классно было бы увидеть твое решение по рефакторингу этого приложения
Да, хорошая идея.
Спасибо. Полезное видео.
@@Aluston1783 спасибо! Лайк, подписка
Блин, а я думал щас 40 минут про теток из троллейбуса будут рассказывать и че с ними делать…
скоро будет, подписывайся!
Читали статью "Как dhh организует контроллеры" ? Вы так делаете? Сейчас так делают?
@@lI-bh5xt а можешь дать ссылку?
Это ещё ладно, у меня на работе в проекте контроллеры со всей логикой, там прямо в них инжектится uow и совершается вся работа вплоть до чтения или записи бд. Там методы вместе с приватными могут в сумме могут составлять сотни строк кода. Все борюсь с этим, топлю за то чтобы создавать слой бизнес логики, чтобы в контроллерах оставлять только try-catch, обращение к сервису и возврат результата.
бороться с teamlead сложно, если он не разделяет твое видение
А зачем все время пытаться отнести какую то часть кода к какой-то части MVC? У тебя есть набор каких-то классов, например services или interactors и ты четко определяешь зону их отвественности
затем, чтобы не допускать размазывания логики обработки запроса, например, которая принадлежит контроллеру и не сможет полностью переехать в сервисы. Кроме этого, это грязный уровень и смешивание его с бизнес-логикой затрудняет тестирование.
В конкретных случаях это может пока не доставлять проблем. Например, итог данного рефакторинга - волне поддерживаемый.
Нарушать можно, просто нужно понимать, что именно ты нарушаешь, чтобы понять, как потом улучшать
затем, чтобы не допускать размазывания логики обработки запроса, например, которая принадлежит контроллеру и не сможет полностью переехать в сервисы. Кроме этого, это грязный уровень и смешивание его с бизнес-логикой затрудняет тестирование.
В конкретных случаях это может пока не доставлять проблем. Например, итог данного рефакторинга - волне поддерживаемый.
Нарушать можно, просто нужно понимать, что именно ты нарушаешь, чтобы понять, как потом улучшать
@@SergeiUdalov Так ты и не будешь допускать протекания. У контроллера своя ответственность, у интерактора своя, у презенетера своя и т.д. Не достаточно ли определить ответственности и не завязываться на MVC?
@@IvanRudskikh если мы в интеракторе оперируем объектом params, то к нам протечет логика обработка и подготовки параметров. В интеракторы стоит передавать уже типизированные, валидированные по схеме параметры.
Cамое печальное, то что бизнесу в целом пофиг, насколько жирны контроллеры и какими частями речи называются классы. Работает и ладно.
До поры пока это все не будет влиять на скорость (стоимость) разработки, но много проектов просто не доживает до того периода.
Мы не бизнес. Мы разработчики. А хорошему разработчику важна поддерживаемость кода (не говнокода).
Так им и должно быть пофиг. Они нанимают экспертов, чтобы они грамотно писали код.
@@Deletedeletedelete мы, как хорошие разработчики, должны уметь обосновать, почему мы работаем так или иначе
@@Deletedeletedelete Всё хорошо в меру. Если стремиться к чистоте без всякой меры, можно превратиться в душного коллегу, который саботирует работу, отказываясь аппрувить PR, если он не соответствует его извращённым представлениям о качественном коде.