Интересно, после того как закончится эра блогов с постами и комментариями, какой оторванный от реальной жизни пример станет следующим героем интернет-чтива для хеллоуворлд-разработчиков?
Я правильно понял смысл статьи, секрет успеха для блогера — не контент, а комплексная стратегия продвижения и все усилия нужно направлять на покупку подписчиков? Или всё же не так прочитал?
В одну строчку? Появились ORM которые читают мысли? Любой запрос сложнее «загрузи сущность по ID» — всегда несколько строк. И чем сложнее запрос, тем больше строк нужно написать для ORM, в сравнении с текстом SQL запроса.
С сырым SQL — создать коннект, выполнить запрос? Ровно так же, как и с ORM нужно получить сессию и отправить запрос на выполнение. Ровно тот же самый код
А мне кажется в этом утверждении скрыт софизм! При наличии ORM, у меня в 6 местах будет один и тот же код по генерации этого «SQL» запроса. И поэтому я тоже эту простыню вынесу в отдельный метод. И, по итогу, при отсутствии ORM у меня в методе будет понятный SQL-запрос, а при использовании SQL — будет того же объёма код, генерящий этот запрос в терминах ORM, и как уже написали ниже, до результирующего SQL ещё поди доберись.
Вообще, как по мне, так с ORM ты по итогу приходишь к тому, что оборачиваешь их ещё одним слоем абстракции как раз из-за того, чтобы не дублировать код построения запросов. И в итоге понимаешь что на самом деле тебе хочется просто удобно (за минимум манипуляций) мапить результат выполнения запроса на сущность, сохранив возможность писать чистый SQL
Посыл моего комментария был чуть другой: зачем задавать подобные вопросы? Что они расскажут о кандидате? Вот, допустим, человек не знает отличие @RestController от Controller, почему существуют Service, Component и Repository. И что нового в Spring 5.0. Действительно ли с подобным соискателем не стоит продолжать дальнейший разговор?
Ответы на почти все эти вопросы гуглятся за пару минут. Потому что являются частными случаями или ответами на вопрос "а на какие кнопки нужно нажать, чтобы во фреймворке Х сделать всем известную и понятную вещь У". Подобное действительно ещё спрашивают?
Знаете что самое занятное в данной ситуации. Вы заморачиваетесь про лишние буфферы памяти, пытаетесь предусмотреть какие-то оптимизации и прочее. А на практике в этом всём нет смысла, потому что вы не знаете как устроен ReadEntities. И постоянно делаете свои предположения (основанные лично на вашем опыте) о том, как он там что делает. А может он там внутри 50 раз бегает по всей переданной коллекции. И тогда очень плохо, что ему позволено на вход получить IEnumerable, а лучше бы это был IList. Или же разработчик этого метода наоборот знал, что да, придётся 50 раз в случайном порядке пробежаться по переданной коллекции, поэтому 1й же строчкой делает .ToList(); Или же ещё лучше — разработчик этого метода бежит по коллекции последовательно, всего 1 раз и заодно во время итерирования и проверил, а было ли ему передано хоть что-то.
А вы тут со своим «может возникнуть ситуация, когда выполняется ненужный ресурсоемкий запрос». Может. Как и ещё тысяча других, более ужасных.
Поэтому нужно не усложнять код (всевозможными условиями, обёртками, бла-бла), а наоборот — упрощать (более точным или гранулярным API, етц). Меньше кода, меньше абстракций — дешевле это счастье поддерживать и быстрее отправлять в продакшн.
Зачем вы спрашиваете меня про суммирование миллиарда чисел? Конкретная задача — конкретное решение.
А вот статья как раз про общий случай. И на ровном месте мы зачем-то получаем несколько десятков строк кода, которые кому-то нужно понимать и поддерживать. Зачем — автор так и не пояснил. При том, что даже в общем случае задача решается строчки в 3 кода, а в частных (мы же практические задачи решаем, верно? А не диванные теоретики, которые программируют ради программирования) — вообще бесплатно.
Не вижу никакой логики в вашем ответе, извините. Наоборот, вы открыто указали на то, что целенаправленно мешаете человеку пользоваться заработанными деньгами.
Кстати, спасибо за текст письма от ЦБ. Нашёл в нём пункт:
«Одновременно отмечаем, что уплата налогов и иных обязательных
платежей в бюджетную систему Российской Федерации в размере ниже
обозначенного уровня не является единственным определяющим фактором
для «автоматического» признания факта совершения клиентом
сомнительных операций.»
Т.е. и слово «рекомендация» трактуется как «требование», и слово «и» при перечислении критериев — как «или», я правильно вас понимаю?
Я бы даже по-другому сказал: это именно рекомендации. И ЦБ в своих рекомендациях не говорит, что нужно людям повышать тарифы или иными способами достигать метрики в 0.9%
Спасибо! Пока бы подобное не бомбануло в проде, сам бы вряд ли догадался!
С сырым SQL — создать коннект, выполнить запрос? Ровно так же, как и с ORM нужно получить сессию и отправить запрос на выполнение. Ровно тот же самый код
Вообще, как по мне, так с ORM ты по итогу приходишь к тому, что оборачиваешь их ещё одним слоем абстракции как раз из-за того, чтобы не дублировать код построения запросов. И в итоге понимаешь что на самом деле тебе хочется просто удобно (за минимум манипуляций) мапить результат выполнения запроса на сущность, сохранив возможность писать чистый SQL
Ответы на почти все эти вопросы гуглятся за пару минут. Потому что являются частными случаями или ответами на вопрос "а на какие кнопки нужно нажать, чтобы во фреймворке Х сделать всем известную и понятную вещь У". Подобное действительно ещё спрашивают?
А вы тут со своим «может возникнуть ситуация, когда выполняется ненужный ресурсоемкий запрос». Может. Как и ещё тысяча других, более ужасных.
Поэтому нужно не усложнять код (всевозможными условиями, обёртками, бла-бла), а наоборот — упрощать (более точным или гранулярным API, етц). Меньше кода, меньше абстракций — дешевле это счастье поддерживать и быстрее отправлять в продакшн.
Давайте не будем тратить время на обсуждения элементарных истин про память, алгоритмическую сложность и прочее
А вот статья как раз про общий случай. И на ровном месте мы зачем-то получаем несколько десятков строк кода, которые кому-то нужно понимать и поддерживать. Зачем — автор так и не пояснил. При том, что даже в общем случае задача решается строчки в 3 кода, а в частных (мы же практические задачи решаем, верно? А не диванные теоретики, которые программируют ради программирования) — вообще бесплатно.
Бывает. Если что, любой вариант будет потреблять хотя бы O(N).
Кстати, спасибо за текст письма от ЦБ. Нашёл в нём пункт:
«Одновременно отмечаем, что уплата налогов и иных обязательных
платежей в бюджетную систему Российской Федерации в размере ниже
обозначенного уровня не является единственным определяющим фактором
для «автоматического» признания факта совершения клиентом
сомнительных операций.»
Т.е. и слово «рекомендация» трактуется как «требование», и слово «и» при перечислении критериев — как «или», я правильно вас понимаю?