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

красивое и чистое решение в мире jvm — Spark. linq сильно примитивней. в спарке вшит прямо свой оптимизатор, ленивое исполнение, до кучи масштабируется в том числе и на множество узлов.

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


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

Роли тоже прописываются в токене. При изменении ролей нужно выписать новый токен.

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

T>Роли тоже прописываются в токене. При изменении ролей нужно выписать новый токен.

а как ты узнаешь, что роль была изменена?

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

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

Ну сделай меньше время жизни токена Скорее всего время реакции на спам-бота будет в разы больше, чем время жизни токена. В крайнем случае я бы лучше поставил простейший in-memory-cache и проверял в нем токены на отзыв в одном месте в middleware, а не помнил об этом при каждом обращении к базе.

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

Z>а как ты узнаешь, что роль была изменена?

Не очень понял вопрос. В смысле как клиент узнает, что ему нужно обновить токен? Ну разные есть варианты. Самое простое — после ивалидации старого токена у него сами появятся новые роли. В windows после добавления пользователя в группу он для применения должен сделать login\logout, это по сути тоже самое.

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

Z> если вопрос просто про LINQ, то на других языках это сделано, как правило, гораздо лучше.

Так где посмотреть более удачные примеры-то?

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

AA>Вопрос: нужно ли оно?

Нужно.

AA>Иногда там такое получается что проще и БЫСТРЕЕ написать десяток запросов руками, чем изучать возможности и ограничения библиотеки.

Изучается оно элементарно. Но главное — вы получаете контроль типов во время компиляции.
Если вы сделаете ошибку в SQL-запросе, то узнаете вы об этом только в рантайме — т.е. в самом лучшем случае, при запуске теста. В худшем — когда что-нибудь падает в продакшне.

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

vsb>Но нужна ли такая концепция на практике?

Удобно же. Почему нет?

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

Когда писал на шарпе, использовал в юниттестах очень активно. Да, для простейших случаев было достаточно передать коллекцию объектов в тест. В более сложных случаях использовал In-Memory DB типа SQLite.

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

Streams API, в общем-то, довольно неплох. Я бы предпочёл LINQ, но за неимением его в джаве, Streams API очень выручает.

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

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

AK>Streams API, в общем-то, довольно неплох. Я бы предпочёл LINQ, но за неимением его в джаве, Streams API очень выручает.

По-моему это очень примитивный и неудачный API. Во-первых нет никакой поддержки со стороны языка. Во-вторых даже простейшие операции требуют бойлерплейта в виде stream().xxx.collect(yyy). В-третьих он не работает с проверяемыми исключениями (как бы я к ним не относился, но они до сих пор являются частью языка, куча API до сих пор их бросает, поэтому такой фундаментальный API, как streams должен работать с ними). В-четвёртых навязывается ленивая модель. В-пятых даётся "прозрачная" возможность запускать операции в нескольких потоках, которая лично мне никогда не была нужна. Ну и в-шестых, но в то же время на мой взгляд в самых главных — реализация просто ахтунг. Сколько раз я пытался вкурить, кто там на ком сидит, столько раз я сдавался. Внутрях всё неимоверно переусложнено, вероятно из-за "в-пятых".

За неимением лучшего, конечно, и такое пойдёт. Но, например, в том же Kotlin всё сделано куда адекватней.

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

AK>Так где посмотреть более удачные примеры-то?

на том же Swift/F# синтаксис функциональщины намного приятнее, чем на сишарпе.

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

vsb>За неимением лучшего, конечно, и такое пойдёт. Но, например, в том же Kotlin всё сделано куда адекватней.

По этому Java-у откладываем в сторонку, и пишем на скале)

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

Gt_>красивое и чистое решение в мире jvm — Spark. linq сильно примитивней. в спарке вшит прямо свой оптимизатор, ленивое исполнение, до кучи масштабируется в том числе и на множество узлов.

Наелся я этим спарком... самое лучшее, что он умеет оптимизировать, это подсчет слов и вычисление Pi.

Gt_>>красивое и чистое решение в мире jvm — Spark. linq сильно примитивней. в спарке вшит прямо свой оптимизатор, ленивое исполнение, до кучи масштабируется в том числе и на множество узлов.

O>Наелся я этим спарком... самое лучшее, что он умеет оптимизировать, это подсчет слов и вычисление Pi.

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

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

PJ>"что либо подобное" это какое-как вкоряченная монада для коллекций? На "других языках" это сделано гораздо лучше и не в виде частного случая для коллекций.

Механика LINQ никак не привязана к коллекциям, зачем глупости писать если не в теме?

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

S>

Generics

Дженерики были добавлены до LINQ

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

S>>можно написать 1 раз, а использовать на множестве разных СУБД, не вникая в тонкости каджой из них.
VC>нельзя

Наличие реальных успешных проектов, в которых либо вообще не приходилось, либо приходилось вникать крайне редко однозначно говорит, что можно.

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

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

Неправильно понимаешь. Концептуальная фишка linq это использование типов дотнета для построения запросов к БД.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>можно написать 1 раз, а использовать на множестве разных СУБД, не вникая в тонкости каджой из них.
VC>>нельзя

НС>Наличие реальных успешных проектов, в которых либо вообще не приходилось, либо приходилось вникать крайне редко однозначно говорит, что можно.

можно поддерживать несколько СУДБ. я сам немного в этом поработал (MSSQL, Postgres, SQLite & MySQL). С интеграционными тестами для всех СУДБ разных версий. Тут первый затык у таких как Шмля. Так что написать раз не вникая — нельзя. Он упрется тупо в миграции. Идентити, GUID, дефолтовые даты да и дефолты в базе в EF надо руками для каждой БД писать. разные они.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Неправильно понимаешь. Концептуальная фишка linq это использование типов дотнета для построения запросов к БД.

Это любое ORM умело еще до, а вот построение дерева запросов, встроенное в язык, плюс провайдеры -- действительно
ноу-хау linq.

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

VC>Идентити, GUID, дефолтовые даты да и дефолты в базе в EF надо руками для каждой БД писать. разные они.

Возьми FluentMigrator, там с этим полегче.