Ваше мнение о LINQ to SQL

Доброго времени суток!!!
Решил самую малость засунуть нос в технологии работы с БД и сразу возник вопрос. Зачем нужен, например, DataAdapter, если есть LINQ, в котором все делается гораздо проще. Возможно, он не совсем гибкий, или работа через адаптер имеет грандиозные преимущества?
В общем, очень хотел бы услышать Ваше мнение, в чем преимущества каждого. И какие еще есть восхитительные способы работать с базами данных(кроме EF)?
P.S Вы, скорее всего, итак это прекрасно поняли, но, на всякий случай, еще раз уточню, что я зеленый настолько, насколько это возможно и был бы крайне признателен, если не закидают всем, чем можно за, скорее всего, тупые вопросы.
Заранее выражаю безграничную благодарность.

0

Сообщение от nicolas2008 ну одно другому не мешает. ORM для CRUD и большинства запросов, SQL views и хранимые процедуры для сложных

Так блин я об этом уже 4 раза написал в этой теме

0

Сообщение от aquaMakc ORM - это удобно. Это очень удобно, особенно, если на полную использовать ООП и всякие вытекающие из него IoC и другие SOLID. Но слова "гибкость" и "производительность" не на его стороне.

Я говорил не о ORM в целом, а конкретно о EF\EF Core. Это не единственная ORM и точно не самая гибкая. LinqToDb намного гибче.

Сообщение от aquaMakc Ну так EF тоже так может. Сам не пробовал, но мануалы говорят, что может.

Вы не поняли. Это совсем другое. Я не о прямом вызове процедуры для получения выборки, а про вызов пользовательских функций внутри Select, для преобразования каких-то полей прямо во время выборки. EF так даже близко не может. Хотя в реальности вещь-то полезная, хоть и не то, чтобы дико распространённая.

Сообщение от aquaMakc Использование хранимок практически полностью исключает SQL-инъекции.

SQL-инъекции исключаются использованием параметризованных запросов. Код вызова хранимых процедур (без параметризации) точно так же уязвим к инъекциями. Это же такой же запрос, блин)

Добавлено через 6 минут

Сообщение от nicolas2008 ORM для CRUD и большинства запросов, SQL views и хранимые процедуры для сложных.

Моя практика показывает, что переход к голому SQL нужен не для реализации сложных запросов, а когда требуется использовать какие-то возможности СУБД до которых не можно дотянутся через ORM, но которые критически важны. Какие-нибудь рекурсивные CTE, SELECT FOR UPDATE и прочие WITH TABLOCKX.

Как раз сложные (большие) запросы может быть проще реализовать именно с использованием EF \ LinqToDb в связке с AutoMapper для переиспользования проекций.

0