Как мне кажется, правильнее было бы назвать это видео не ".. улучшения приложения ..", а скорее "улучшения вашего исходного кода" или что-то в этом роде
Я придерживаюсь разделения по функциональности - пакеты сервисов, репозиториев и контроллеров Если у вас немного сущностей, то это удобно Подход разделения по бизнес логике удобен, если вы создаёте отдельные модули, которые независимо друг от друга могут работать, тогда у вас в одном пакете находится и контроллер и сервис и репозиторий и бизнес класс
так как сервисы могут взаимодействовать между собой, то они должны обмениваться сущностями напрямую, а дто нужно, чтобы отдавать данные клиенту. Использование дто внутри сервисов добавит много лишнего кода для маппинга внутри приложения
Шикарное видео, но пожалуйста, сними видео где каждому пункту уделено по 5-20 минут. Потому что некоторые вещи понимаешь, а некоторые вообще не понимаешь как реализовать
@@ilyalisov понимаю базовое: использовать спринг инициалайзер, либо что-то внедрил уже. Не понимаю как делать exception в спринге в "ком" проектах - через контроллер эдвайс? Но не знаю правильно ли я делал
В описании можно найти ссылку на презентацию. Если вам понравился данный формат, то дайте знать!
Очень полезно и хорошая подача.
Спасибо❤
благодарю
Очень хорошо. Включу эту презентацию в свой курс лекций по Рефакторингу.
спасибо!
очень полезная информация в сжатом виде
Огонь! Спасибо
Как мне кажется, правильнее было бы назвать это видео не ".. улучшения приложения ..", а скорее "улучшения вашего исходного кода" или что-то в этом роде
И еще вспомнил: почему в проекте валидация User не у сущности, которую мы сохраняем в БД, у DTО?! Спасибо!
мы получаем сущность от клиента (дто) на контроллер, и на этом этапе валидируем, мы уверены, что внутри сервисов сущность будет валидна
Можно подробнее про пункт 4. Какой подход выбрать, где про это можно почитать\посмотреть подробнее?
Я придерживаюсь разделения по функциональности - пакеты сервисов, репозиториев и контроллеров
Если у вас немного сущностей, то это удобно
Подход разделения по бизнес логике удобен, если вы создаёте отдельные модули, которые независимо друг от друга могут работать, тогда у вас в одном пакете находится и контроллер и сервис и репозиторий и бизнес класс
@@ilyalisov Большое спасибо за ответ
Илья приветствую!!! Подскажи, пжл, почему маппинг нужно делать не в сервисной части, а в контроллере?! Спасибо!!!
так как сервисы могут взаимодействовать между собой, то они должны обмениваться сущностями напрямую, а дто нужно, чтобы отдавать данные клиенту. Использование дто внутри сервисов добавит много лишнего кода для маппинга внутри приложения
@@ilyalisov Я понял! Спасибо огромное за обратную связь!!!!!
Только можно нарваться на LazyInitialisationException, т.к. Транзакция уже закрыта.
Шикарное видео, но пожалуйста, сними видео где каждому пункту уделено по 5-20 минут.
Потому что некоторые вещи понимаешь, а некоторые вообще не понимаешь как реализовать
спасибо, расскажите подробнее какие пункты вызвали трудности?)
@@ilyalisov понимаю базовое: использовать спринг инициалайзер, либо что-то внедрил уже.
Не понимаю как делать exception в спринге в "ком" проектах - через контроллер эдвайс? Но не знаю правильно ли я делал
@user-pq9zz8gs4s а как ты сделал?
У Нельсона есть ещё 10 советов по этой теме. ruclips.net/video/CT8dbbe783s/видео.html&ab_channel=Amigoscode
А когда видос по JAcoCo
на этой неделе
2оф21 гойда