Статья про то, что почему-то правильно начинать с БД, то есть хранения данных, а не с работы с ними, как будто основная задача — это хранить их, а не совершать над ними какие-то действия. Как по мне такой подход изрядно устарел…
В статье не просто про схему, там как противопоставление подходу code-first, который якобы несет боль и страдание. Ну, так db-first несет не меньше боли, поскольку очень сложно танцуя «от схемы» не начать закладывать в эту схему логику. В том же Оракле у нас получалось примерно так — создадим схему, придумаем таблички, свяжем их ключами… А как проверить, что схема вышла удачной? Ну, селектом же. Вот уже появился первый селект, который выбирает данные, а то и несколько. Вы еще ни строчки кода не написали, а уже связаны неким контрактом, который был рожден учитывая только одни интересы — интересы БД, поскольку интересы кода никем представлены не были ввиду отсутствия такового. Не велика беда? Не велика. До тех пор, пока благодаря такому проектированию не случиться ситуация, когда «вот эту предобработку удобнее сделать на стороне БД, заведем пару триггеров на инсерт и апдейт...» — готово дело! У вас есть триггеры, а, скорее всего, еще и хранимка. И как теперь отвечать на вопрос «Как работает эта функциональность?» Правильный ответ — в болью, поскольку для нахождения ответа вы пойдете в код, размотаете его до какого-то уровня, ВНЕЗАПНО провалитесь в БД, где есть своя логика, размотаете ее, вернетесь в первый код… В моем случае весь этот психоз был накрыт еще web-частью, так что бутерброд получался совершенно не съедобным.
Вместо «Java[любой другой язык] first» подхода, который выведет вас на длинную дорожку, полную боли и страданий, как только проект начнет расти.
До чего категорично-то… А как насчет длинной дорожки танцев «от базы», которая в итоге приведет к тому, что приложение зависит от БД чуть более чем полностью, потому что изрядная часть логики переползла именно туда? Я не раз и не два наблюдал, как функционал, который начинался, как «select с обработкой» постепенно превращался сначала в «сложные select с триггерами с последующей обработкой», а потом и в «сложные select с триггерами и прочими джобами, а так же кучей хранимых процедур с последующей обработкой или даже без оной». После чего приложения вырождались по сути дела до гейтов к базе, в которой была сосредоточена вся логика. Естественно никто уже толком не понимал, как это все работает, и уж точно не мог нормально наращивать функционал. Вот такая по моему опыту цена проектирования «от базы».
Я примерно об этом же — мантра, призванная обосновать нужность чего-то, при этом по сути, если эту мантру разобрать, то получается что-то вроде «давайте вы сами тут поучитесь, а мы сделаем вид, что ваши успехи — наша заслуга, а ваши провалы, соответственно — это ваши провалы...»
Всю дорогу рассказывали, что еще в школе нужно «учиться учиться», потому что в универе без этого никуда, а теперь, оказывается, этому в магистратуре учат…
он показывал лучший результат по производительности
По производительности чего? Записи в лог на единицу времени? Если логгирование бьет по производительности системы, то, думаю, нужно не логгеры менять, а присмотреться к консерватории — что-то там не так…
А в чем удобство? Вы описали обычную настройку логгера, logback настраивается примерно так же, с той разницей, что, скорее всего, отдельно подключать его не понадобится, поскольку он идет прицепом за spring-boot-starter-web (https://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html). Настройка аппендеров ничуть не сложнее, разве что xml'ник называется по другому. А насчет
я сейчас скажу, как сделать действительно удобно. Во-первых подключите lombok. Во-вторых не слушайте эстетов, которые при слове lombok начинают шипеть и плеваться ядом. В-третьих в lombok.config напишите:
lombok.log.fieldName=logger
Готово, теперь достаточно поставить аннотацию @Slf4j, и можно использовать ту самую переменную logger.
Поддерживаю. сам перешел к подобному подходу, когда база стала не просто узким местом, но причиной реальных тормозов.
А потом вообще стал использовать in-memory хранилища, а в БД только персистинг. Отзывчивость возросла в разы. Потребление памяти, правда, тоже :D
А ответ на миллион заключается в том, что в реальной жизни какой-нибудь сервис авторизации выполняет кучу совершенно разных действий, но при этом внезапно начинает соответствовать SOLID, как только появляется формулировка «он решает задачу авторизации пользователей»! С формальной точки зрения все зависит от того, как дробишь задачи, как группируешь. С практической нужно для начала подумать чего мы SOLIDом добиваемся, а дальше уже смотреть в конкретный случай — добились? не добились?
До чего категорично-то… А как насчет длинной дорожки танцев «от базы», которая в итоге приведет к тому, что приложение зависит от БД чуть более чем полностью, потому что изрядная часть логики переползла именно туда? Я не раз и не два наблюдал, как функционал, который начинался, как «select с обработкой» постепенно превращался сначала в «сложные select с триггерами с последующей обработкой», а потом и в «сложные select с триггерами и прочими джобами, а так же кучей хранимых процедур с последующей обработкой или даже без оной». После чего приложения вырождались по сути дела до гейтов к базе, в которой была сосредоточена вся логика. Естественно никто уже толком не понимал, как это все работает, и уж точно не мог нормально наращивать функционал. Вот такая по моему опыту цена проектирования «от базы».
Всю дорогу рассказывали, что еще в школе нужно «учиться учиться», потому что в универе без этого никуда, а теперь, оказывается, этому в магистратуре учат…
Вы знаете, что мне пришло в голову при прочтении этой фразы? Дяденьки в тельняшках устраивающие заплывы в фонтанах.
(с)
Да что ж такое, никому верить нельзя!
По производительности чего? Записи в лог на единицу времени? Если логгирование бьет по производительности системы, то, думаю, нужно не логгеры менять, а присмотреться к консерватории — что-то там не так…
я сейчас скажу, как сделать действительно удобно. Во-первых подключите lombok. Во-вторых не слушайте эстетов, которые при слове lombok начинают шипеть и плеваться ядом. В-третьих в lombok.config напишите:
Готово, теперь достаточно поставить аннотацию @Slf4j, и можно использовать ту самую переменную logger.
А потом вообще стал использовать in-memory хранилища, а в БД только персистинг. Отзывчивость возросла в разы. Потребление памяти, правда, тоже :D