А при чём тут вся сеть, если я высказал только своё мнение? То, что конкретно вам ОС от Microsoft не нужна уже 15 лет - это замечательно, но это говорит только лишь о том, что конкретно вам за 15 лет не пришлось столкнуться с её необходимостью.
Что куда передавать по данным - вопрос к разработчику.
Ну, вот я и задаю конкретный вопрос разработчику, пропагандирующему "просто другой подход, Entity - это умный объект, со своими методами". А он отмазывается общими фразами, не давая ответ на поставленный вопрос.
Нужно смотреть на решаемую задачу.
Есть пользователь в базе (UserEntity) для него, например, с госуслуг нужно притащить ФИО. Мне работу по общению с госуслугами прямо в умном UserEntity придётся реализовывать, либо вся "умность" этой сущности будет заключаться в том, чтобы делегировать вызов метода, загружающего ФИО, соответствующему методу сервиса, который будет передан в качестве аргумента, либо как-то по-другому внедрён в сущность.
Всё работа - поднял объект из базы -> вызвал на нем метод с параметрами -> объект поменял состояние -> сохранил измененный объект.
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 рекомендует делать синглетоны
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
А при чём тут вся сеть, если я высказал только своё мнение? То, что конкретно вам ОС от Microsoft не нужна уже 15 лет - это замечательно, но это говорит только лишь о том, что конкретно вам за 15 лет не пришлось столкнуться с её необходимостью.
Ну, вот я и задаю конкретный вопрос разработчику, пропагандирующему "просто другой подход, Entity - это умный объект, со своими методами". А он отмазывается общими фразами, не давая ответ на поставленный вопрос.
Есть пользователь в базе (UserEntity) для него, например, с госуслуг нужно притащить ФИО. Мне работу по общению с госуслугами прямо в умном UserEntity придётся реализовывать, либо вся "умность" этой сущности будет заключаться в том, чтобы делегировать вызов метода, загружающего ФИО, соответствующему методу сервиса, который будет передан в качестве аргумента, либо как-то по-другому внедрён в сущность.
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. Нигде в ней не говорится, что это единственно верный вариант.
То, что эти примеры начали бездумно копировать, полагаясь на авторитет авторов, говорит лишь о том, что люди по своей сути ленивы и, если можно не думать, предпочитают именно так и поступать.
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
Это да, но оно не везде есть именно в таком виде. А вот без логеров продакшн-кода я не видел уже давно.