Спасибо! Хорошее замечание. Действительно, select уже устарел. Но он до сих пор часто используется в качестве примеров в других источниках (вероятно из-за своей простоты). Я не стал отходить от традиций.
Как и многие другие источники(книги, статьи, туториалы и т.д.) данная статья представляет собой компиляцию уже существующих идей и собственного видения с опытом. Я не ставил целью открыть колесо. Мне просто хотелось поделиться существующими знаниями на случай, если кому-то это пригодится.
Мне кажется большая вариация статей на одну тему — не так уж и плохо. Посмотрите какое количество учебников, статей, видео курсов по математическому анализу существует. Тем не менее до сих есть люди, которые пишут новые. Мне кажется, это отлично.
Спасибо за статью! Один вопрос. В статье говорится о том, что продакт должен быть строгим лидером для своей команды. Так ли это? Ведь все работают по SCRUM системе(по крайней мере в лабе), где каждый член команды должен быть равным. Кроме того, бывают случаи, когда команда отказывается от продакта и меняет его.
Согласен, но ведь за одну статью целую реактивную систему не построишь. Именно поэтому я и решил оставить такой P.S. Здесь я постарался сосредоточится на том как выглядит работа в таком режиме. Например, обратите внимание на действия в сервисном слое. Они отличаются от привычного декларативного стиля.
Логику выборки данных из базы мы реализуем в сервисе только в качестве показательного примера. В продакшене, конечно, это надо делать через запрос на стороне базы. Здесь хотел показать как выглядит работа с бизнес логикой в слое сервиса, вот и все. Именно поэтому я написал: «Конечно, такую логику можно возложить на базу данных, но здесь я хотел бы обратить внимание как это будет выглядит в сервисе».
И второй вопрос. Кеш БД, на сколько я понимаю, остается и реализуется на уровне взаимодействия драйвера(обратите внимание, что здесь используется специальный драйвер) и базы.
Во-первых, сервисы бывают разные и разные правила взаимодействия между ними могут быть. Сильно зависит от конечной системы.
Во-вторых, тут показывается пример с 404 для простоты. Вы легко можете заменить его, например, на 400 при валидации некоторых полей и в ответном сообщении показать какое поле с ошибкой.
Мне кажется вы сильно упрощаете. Если все было бы так, то и такого разнообразия интрументов не было бы. Люди просто отдавали статус при любой ошибке и все.
Обычно для этого используется СУБД. HashMap тут только для простой демонстрации. Но вообще, да. Если добавить еще метод на создание пользователей, то следует использовать ConcurrentHashMap.
Мне кажется большая вариация статей на одну тему — не так уж и плохо. Посмотрите какое количество учебников, статей, видео курсов по математическому анализу существует. Тем не менее до сих есть люди, которые пишут новые. Мне кажется, это отлично.
И второй вопрос. Кеш БД, на сколько я понимаю, остается и реализуется на уровне взаимодействия драйвера(обратите внимание, что здесь используется специальный драйвер) и базы.
Во-первых, сервисы бывают разные и разные правила взаимодействия между ними могут быть. Сильно зависит от конечной системы.
Во-вторых, тут показывается пример с 404 для простоты. Вы легко можете заменить его, например, на 400 при валидации некоторых полей и в ответном сообщении показать какое поле с ошибкой.
Мне кажется вы сильно упрощаете. Если все было бы так, то и такого разнообразия интрументов не было бы. Люди просто отдавали статус при любой ошибке и все.