Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Shmj, Вы писали:

S>>LINQ проще и удобнее чем SQL. Тем более можно написать 1 раз, а использовать на множестве разных СУБД, не вникая в тонкости каджой из них.
AA>Проще когда вы linq хорошо знаете.

Что, слишком много операторов? Выучил и пишешь в LINQ Query syntax. От SQL практически не отличается.

Здравствуйте, Danchik, Вы писали:

D>Что, слишком много операторов? Выучил и пишешь в LINQ Query syntax. От SQL практически не отличается.

Еще можно смирится с Where vs from .. select ..
но когда ты пишешь вроде очевидные вещи, а C# бьет по рукам. то объекты нельзя создавать в Select, то оказывается Linq не дружит с Sql.
Если бы не торопили с реализацией все бы делал при помощи sql.

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Danchik, Вы писали:

D>>Что, слишком много операторов? Выучил и пишешь в LINQ Query syntax. От SQL практически не отличается.

AA>Еще можно смирится с Where vs from .. select ..
AA>но когда ты пишешь вроде очевидные вещи, а C# бьет по рукам. то объекты нельзя создавать в Select, то оказывается Linq не дружит с Sql.
AA>Если бы не торопили с реализацией все бы делал при помощи sql.

Это ты про EF говоришь?

Здравствуйте, Danchik, Вы писали:

D>Это ты про EF говоришь?
ага, руки связыает порой.

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Danchik, Вы писали:

D>>Это ты про EF говоришь?
AA>ага, руки связыает порой.

Там да, надо аккуратно плясать. Шаг влево, шаг впарво — can not be translated.

Здравствуйте, varenikAA, Вы писали:

D>>Это ты про EF говоришь?
AA>ага, руки связыает порой.

как то после нагрузочных тестов сервиса, использующего EF, перенес все к чертовой матери на хранимые процедуры. и только за счет этого получил увеличение скорости отклика сервиса примерно в 10 раз и в миллион раз — снижение нагрузки на память.

Здравствуйте, VladCore, Вы писали:

VC>ты забыл итераторы и foreach. они есть в JS благодаря чему и есть linq
В JS попадалась сторонняя библиотека, реализующая плюшки LINQ

Здравствуйте, Mihas, Вы писали:

VC>>ты забыл итераторы и foreach. они есть в JS благодаря чему и есть linq
M>В JS попадалась сторонняя библиотека, реализующая плюшки LINQ

она так и называется. я выше написал, но форматирование его зеленым закрасила только сейчас заметил

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Shmj, Вы писали:

S>>LINQ проще и удобнее чем SQL. Тем более можно написать 1 раз, а использовать на множестве разных СУБД, не вникая в тонкости каджой из них.
AA>Проще когда вы linq хорошо знаете.

А там знать не надо, IDE сама подсказывает, достаточно поставить точку после любой коллекции.

Здравствуйте, zverjuga, Вы писали:

Z>как то после нагрузочных тестов сервиса, использующего EF, перенес все к чертовой матери на хранимые процедуры. и только за счет этого получил увеличение скорости отклика сервиса примерно в 10 раз и в миллион раз — снижение нагрузки на память.

Можно и на хранимках медленные запросы написать, если мозг не включать

Здравствуйте, mrTwister, Вы писали:

T>Можно и на хранимках медленные запросы написать, если мозг не включать

любой запрос, требующий той же аутентификации на EF будет минимум в два раза медленнее, чем в хранимке. потому что EF будет делать два запроса в базу (по сети, что есть очень медленно), которая может находиться на удаленном сервере,- один для получения профиля по токену и обработку его прав доступа, а второй — запрос для получения и обработки порции данных из базы по этому профилю. хранимка все сделает за один запрос. и это самый простой, но базовый пример. не говоря уже о том, что EF сам по себе очень прожорлив к памяти.

Здравствуйте, zverjuga, Вы писали:

Z>любой запрос, требующий той же аутентификации на EF будет минимум в два раза медленнее, чем в хранимке. потому что EF будет делать два запроса в базу (по сети, что есть очень медленно), которая может находиться на удаленном сервере,- один для получения профиля по токену и обработку его прав доступа, а второй — запрос для получения и обработки порции данных из базы по этому профилю. хранимка все сделает за один запрос. и это самый простой, но базовый пример. не говоря уже о том, что EF сам по себе очень прожорлив к памяти.

Не, ну если у вас бизнес-логика живет в базе, то EF действительно не нужен по определению. Но там будет куча других проблем. А в случае с EF, зачем на каждый запрос грузить профиль пользователя?

Вопрос не совсем по теме, но всё же. А оно надо?

Я так понимаю, концептуальная "фишка" LINQ состоит в унифицированном интерфейсе для работы с деревьями объектов и для работы с БД.

Но нужна ли такая концепция на практике? Например ты пишешь код для работы с БД, но подаёшь ему на вход список объектов в юнит-тесте, чтобы заменить БД. Насколько это используется?

Ответ по теме — в Java ничего подобного нет. Есть streams, есть разного рода ORM и псевдо-ORM, но оно всё уродливое и/или основано на хаках. Красивого чистого решения я не видел.

Здравствуйте, mrTwister, Вы писали:

T>Не, ну если у вас бизнес-логика живет в базе, то EF действительно не нужен по определению. Но там будет куча других проблем. А в случае с EF, зачем на каждый запрос грузить профиль пользователя?

потому что это веб-сервис, и все запросы требуют токен пользователя.

Здравствуйте, zverjuga, Вы писали:

Z>потому что это веб-сервис, и все запросы требуют токен пользователя.

Если вы для валидации токена ходите в базу, вы явно что-то делаете не то. Есть же JWT. Ходить в базу надо только один раз при выписывании токена, а дальше только расшифровывать токен, проверять его подпись и атрибуты и для всего этого БД не нужна.

Здравствуйте, vsb, Вы писали:

vsb>Я так понимаю, концептуальная "фишка" LINQ состоит в унифицированном интерфейсе для работы с деревьями объектов и для работы с БД.

С коллекциями. БД — это просто частный случай коллекции. Под понятие коллекции можно свести почти всё, что угодно и ты автоматически получаешь стандартный всем известный расширяемый интерфейс для работы с этим.

Здравствуйте, mrTwister, Вы писали:

Z>>потому что это веб-сервис, и все запросы требуют токен пользователя.

T>Если вы для валидации токена ходите в базу, вы явно что-то делаете не то. Есть же JWT. Ходить в базу надо только один раз при выписывании токена, а дальше только расшифровывать токен, проверять его подпись и атрибуты и для всего этого БД не нужна.

Ещё нужно проверять, не является ли токен отозванным. И для этого как раз нужна база данных в том или ином виде.

Здравствуйте, vsb, Вы писали:

vsb>Ещё нужно проверять, не является ли токен отозванным. И для этого как раз нужна база данных в том или ином виде.

Это делается с помощью ограничения времени жизни токена

Здравствуйте, mrTwister, Вы писали:

vsb>>Ещё нужно проверять, не является ли токен отозванным. И для этого как раз нужна база данных в том или ином виде.

T>Это делается с помощью ограничения времени жизни токена

Очевидно, что имеется в виду отзыв до истечения времени жизни токена. Ты же не будешь каждую секунду новый токен выпускать. Простой пример: ты делаешь форум. На форуме завёлся спамбот. Модератор хочет его забанить. Жмёт бан, а ему пофиг, до истечения срока действия токена ещё час.

Здравствуйте, mrTwister, Вы писали:

T>Если вы для валидации токена ходите в базу, вы явно что-то делаете не то. Есть же JWT. Ходить в базу надо только один раз при выписывании токена, а дальше только расшифровывать токен, проверять его подпись и атрибуты и для всего этого БД не нужна.

это самый минимум проверки, которая проводится над токеном. еще есть роли, у которых разный уровень доступа к данным в базе. также нужно учитывать, что роль у профиля может быть в любой момент изменена как с клиента, так и с админской части. поэтому, любой запрос в сервис требует проверки.