Всё работа - поднял объект из базы -> вызвал на нем метод с параметрами -> объект поменял состояние -> сохранил измененный объект.
Talk is cheap. Show me the code. Как когда-то сказал один небезысвестный товарищ.
Если мне для перевода этой самой сущности из одного состояния в другое требуется в третьесторонний сервис сходить, я буду сервис в метод сущности передавать? А если таких требуемых сервисов хотя бы штуки 4 их тоже все в аргументами передавать или предлагаете инъекции сервисов прямо в сущность?
Сущность - это такая же DTO, только для базы. А цитируемое мною относится к доменным агрегатам, и если уж зашёл разговор, то одна сущность может отображаться в несколько доменов в зависимости от бизнес-операции.
Как костыль, конечно, годно, но лучше, конечно, все эти приседания отправить PR-ом в соответствующий плагин, чтобы это работало из коробки, а не вот эта вот мешанина из xml-я и java-кода.
За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Если вышло обновление - заниматься ретестами каждый раз?
А при чём тут опенсорс? Ретест для mission critical штук нужен при любом изменении, нет?
Если обнаружен баг - отправлять разработчику багрепорт и ждать от него что он все бросит и кинется его исправлять?
Это как раз ситуация с вендорским решением. Если код открыт, то у тебя -всегда- как правило есть возможность залезть в исходники, поправить и даже отправить фикс в апстрим.
очень часто никакого отношения к enumeration не имеет
Именно поэтому enum приватный и напрямую наружу не торчит, потому что его использование обусловлено лишь гарантией единственности экземпляра со стороны самой jvm. Например в гугловой гуаве до появления лямбд через подобный механизм реализованы некоторые функции (Functions.toStringFunction(), Functions.identity(), ...)
GoF его преподносит
Ничего GoF не преподносит. Вообще эта книжка про шаблоны проектирования, и там приведены лишь возможные реализации этих самых шаблонов конкретно на языке java. Нигде в ней не говорится, что это единственно верный вариант.
То, что эти примеры начали бездумно копировать, полагаясь на авторитет авторов, говорит лишь о том, что люди по своей сути ленивы и, если можно не думать, предпочитают именно так и поступать.
как Effective Java рекомендует делать синглетоны
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
Более того использовать Enum для синглетона - это рекомендация из книги Effective Java (имхо анти-рекомендация).
Основная беда enum-ов в качестве синглтонов - это неленивость и протекание ненужных сервису enum-методов. И первое, и второе решается тем, что enum должен быть приватным классом в синглтон-сервисе, а методы сервиса делегируют вызовы единственной константе в этом enum-е.
Spring начал становиться довольно популярным
И теперь его, не думая, пихают везде где нужно и где не нужно.
Singleton стал анти-паттерном
И именно поэтому его использует вышеупомянутый Spring? Синглтон - это просто объект-одиночка в рамках, как правило, приложения. Вне зависимости от механизма реализации данного поведения, будь-то spring, CDI, micronaut, etc.
Talk is cheap. Show me the code. Как когда-то сказал один небезысвестный товарищ.
Если мне для перевода этой самой сущности из одного состояния в другое требуется в третьесторонний сервис сходить, я буду сервис в метод сущности передавать? А если таких требуемых сервисов хотя бы штуки 4 их тоже все в аргументами передавать или предлагаете инъекции сервисов прямо в сущность?
Сущность - это такая же DTO, только для базы. А цитируемое мною относится к доменным агрегатам, и если уж зашёл разговор, то одна сущность может отображаться в несколько доменов в зависимости от бизнес-операции.
Ошибка выжившего, не более. ;)
Потому что аббревиатуры, несуществующие в языке, на который осуществляется перевод, как правило, не переводятся.
Как костыль, конечно, годно, но лучше, конечно, все эти приседания отправить PR-ом в соответствующий плагин, чтобы это работало из коробки, а не вот эта вот мешанина из
xml-я иjava-кода.Не надо превращать
pom-ник вant/gradle-скрипт.А где раздобыть первый? Судя по второму, он должен быть эпичен.
Разработчики этой системы, видимо, хабр не читают.
А что тут такого особенного, что не описано в документации?
... дочитав все новости? ... долистав всю ленту? ... досмотрев весь ютуб?
Ну, вообще-то да. Лень им, понимаешь, на себе носить ребёнка.
За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Начальник или программист?
Как говорится, есть 2 типа разработчиков: те, кто думает, что soft delete - это крутое решение, и другие.
А что поменяется, если это будет не опенсорс?
А при чём тут опенсорс? Ретест для mission critical штук нужен при любом изменении, нет?
Это как раз ситуация с вендорским решением. Если код открыт, то у тебя -всегда- как правило есть возможность залезть в исходники, поправить и даже отправить фикс в апстрим.
Именно поэтому enum приватный и напрямую наружу не торчит, потому что его использование обусловлено лишь гарантией единственности экземпляра со стороны самой jvm.
Например в гугловой гуаве до появления лямбд через подобный механизм реализованы некоторые функции (
Functions.toStringFunction(),Functions.identity(), ...)Ничего GoF не преподносит. Вообще эта книжка про шаблоны проектирования, и там приведены лишь возможные реализации этих самых шаблонов конкретно на языке java. Нигде в ней не говорится, что это единственно верный вариант.
То, что эти примеры начали бездумно копировать, полагаясь на авторитет авторов, говорит лишь о том, что люди по своей сути ленивы и, если можно не думать, предпочитают именно так и поступать.
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
Это да, но оно не везде есть именно в таком виде. А вот без логеров продакшн-кода я не видел уже давно.
Основная беда enum-ов в качестве синглтонов - это неленивость и протекание ненужных сервису enum-методов. И первое, и второе решается тем, что enum должен быть приватным классом в синглтон-сервисе, а методы сервиса делегируют вызовы единственной константе в этом enum-е.
И теперь его, не думая, пихают везде где нужно и где не нужно.
И именно поэтому его использует вышеупомянутый Spring? Синглтон - это просто объект-одиночка в рамках, как правило, приложения. Вне зависимости от механизма реализации данного поведения, будь-то spring, CDI, micronaut, etc.
LoggerFactory.getLogger(MyService.class)из большинства активно используемых логеров передаёт привет.Что за бредятина? Зачем нужен
getInstance(), ежели и так имеется доступ к экземпляру?Но в суд нужно будет предоставить бумажную копию документа с распечатанной же электронной подписью.