Понятно, что нет необходимости использовать Razor если вы используете Web API, но если вы используете ASP.net MVC, то Razor просто шикарен и я не встречал шаблонизатор лучше.
Мне кажется, что можно сформулировать и доказать следующее:
Для любого запроса, который сгенерирован генератором SQL кода, найдется такой запрос, написанный на SQL (возможно в паре с T-SQL), который не будет уступать в производительности сгенерированному.
Что думаете?
>> Но если знать немного SQL, то становится понятно, что linq-orm_ы могут построить проекцию (select) которая выбирает ровно то, что нужно для отображения
Все это прекрасно можно сделать и на SQL.
>> Тогда как в процедурах проекции будут широкие, ибо никто не хочет поддерживать десяток процедур.
Видимо, вам просто не повезло с разработчиком БД. Понятно, что если писать плохой код, то и работать он будет плохо. Кстати, код на EF тоже надо поддерживать.
>> А дальше для узких запросов можно удачно построить покрывающие индексы
А SQL эти индексы использовать не будет?
>> На практике как раз процедуры делают универсальными
Мне кажется, что вам просто не повезло с разработчиком БД. Поверьте и на EF можно писать очень плохо. Вы думаете мало тех, кто не использует проекции вообще и высасывает все данные методом ToList()? Это скорее говорит о низкой квалификации и безалаберном отношении к своей работе, чем об используемых технологиях.
>> Рекурсивные запросы помогают быстродействию?
Вы попросили пример использования особенностей MS SQL. Вот он.
>> За счет чего?
За счет того, что универсальное решение практически всегда проиграет по производительности специализированному. Обратите внимание на то, как автор решает «проблемы» EF? Правильно, он по сути редактирует SQL-запрос, и пытается привести его к адекватному виду.
>> Например?
Например, рекурсивные запросы.
>> Мы все еще о запросах или о массовой обработке?
Вы под запросом понимаете выборку (SELECT) данных? Если да, то о них в частности. На самом деле в наших проектах самые сложные запросы связаны именно с выборкой данных.
>> в разы увеличивает быстродействие
С этим я не могу согласиться.
T-SQL это могучая и крайне гибкая технология. Естественно, что для сложных запросов грамотно написанные хранимые процедуры будут намного более производительные, чем автоматически сгенерированный SQL код EF-ом, так как они могут в полной мере раскрыть все особенности и весь богатейший функционал СУБД MS SQL.
Мы используем EF во всех своих новых проектах, но когда сталкиваемся с действительной необходимостью оптимизации производительности, то мы используем хранимые процедуры, но на проект таких узких мест у нас на пальцах можно пересчитать.
А вот выгода в плане скорости разработки, уменьшения количества ошибок и отсутствие смены контекста между C#, Lynq и SQL, T-SQL при использовании EF приносят очень много позитивного в процесс разработки.
В любом случае надо дождаться релиза EF 7 и проверить. Кстати, я бы не назвал описанные в статье случаи проблемами, хотя бы потому, что автор тут же в статье привел варианты их решения и почти все решения базируются на возможностях EF т. е. это скорее тонкости работы с EF, чем проблемы.
релиз EF7 ожидается в первом квартале 2016 г. Здесь можно посмотреть на некоторые новые возможности EF7:
https://github.com/aspnet/EntityFramework/wiki/Roadmap
EF7 это скорее не продолжение EF6, а переписанная чуть ли не с нуля ORM.
Лень тут не причем. Все зависит от того, что за проект у вас.
Естественно, если у вас высоконагруженный проект с большой БД и сложной логикой запросов к БД, то Entity Framework вам не подойдет, но дело в том, что огромное количество разработчиков разрабатывает стандартные проекты с маленькими БД (до 1 млн. строк). И вот для этих проектов EF приносит кайф. Попробуйте Lynq и вы увидите какое удовольствие писать запросы в стиле lambda expression. Также никто не мешает там где это надо вызвать хранимую процедуру или обратится к СУБД на чистом SQL.
И после вот таких вот решений в сети появляются сравнения производительности Nexus 5 (2013) и Nexus 5X (2015) и второй не может показать ожидаемый результат. Во многом это происходит благодаря включенному по умолчанию шифрованию. Я ничего не имею против шифрование, но пользователь должен иметь возможность его отключать.
Ссылка на сравнение: http://androidinsider.ru/smartfony/nexus-5-protiv-nexus-5x-test-skorosti-rabotyi.html
Только не другое, а хорошее другое. В данном случае это не так.
Насколько ускорилась обработка?
Это не так. Корневых DNS серверов более 500.
Entity Framework отлично подходит для своих задач.
Спасибо вам за диалог.
Для любого запроса, который сгенерирован генератором SQL кода, найдется такой запрос, написанный на SQL (возможно в паре с T-SQL), который не будет уступать в производительности сгенерированному.
Что думаете?
Все это прекрасно можно сделать и на SQL.
>> Тогда как в процедурах проекции будут широкие, ибо никто не хочет поддерживать десяток процедур.
Видимо, вам просто не повезло с разработчиком БД. Понятно, что если писать плохой код, то и работать он будет плохо. Кстати, код на EF тоже надо поддерживать.
>> А дальше для узких запросов можно удачно построить покрывающие индексы
А SQL эти индексы использовать не будет?
Мне кажется, что вам просто не повезло с разработчиком БД. Поверьте и на EF можно писать очень плохо. Вы думаете мало тех, кто не использует проекции вообще и высасывает все данные методом ToList()? Это скорее говорит о низкой квалификации и безалаберном отношении к своей работе, чем об используемых технологиях.
>> Рекурсивные запросы помогают быстродействию?
Вы попросили пример использования особенностей MS SQL. Вот он.
За счет того, что универсальное решение практически всегда проиграет по производительности специализированному. Обратите внимание на то, как автор решает «проблемы» EF? Правильно, он по сути редактирует SQL-запрос, и пытается привести его к адекватному виду.
>> Например?
Например, рекурсивные запросы.
>> Мы все еще о запросах или о массовой обработке?
Вы под запросом понимаете выборку (SELECT) данных? Если да, то о них в частности. На самом деле в наших проектах самые сложные запросы связаны именно с выборкой данных.
С этим я не могу согласиться.
T-SQL это могучая и крайне гибкая технология. Естественно, что для сложных запросов грамотно написанные хранимые процедуры будут намного более производительные, чем автоматически сгенерированный SQL код EF-ом, так как они могут в полной мере раскрыть все особенности и весь богатейший функционал СУБД MS SQL.
Мы используем EF во всех своих новых проектах, но когда сталкиваемся с действительной необходимостью оптимизации производительности, то мы используем хранимые процедуры, но на проект таких узких мест у нас на пальцах можно пересчитать.
А вот выгода в плане скорости разработки, уменьшения количества ошибок и отсутствие смены контекста между C#, Lynq и SQL, T-SQL при использовании EF приносят очень много позитивного в процесс разработки.
https://github.com/aspnet/EntityFramework/wiki/Roadmap
EF7 это скорее не продолжение EF6, а переписанная чуть ли не с нуля ORM.
Естественно, если у вас высоконагруженный проект с большой БД и сложной логикой запросов к БД, то Entity Framework вам не подойдет, но дело в том, что огромное количество разработчиков разрабатывает стандартные проекты с маленькими БД (до 1 млн. строк). И вот для этих проектов EF приносит кайф. Попробуйте Lynq и вы увидите какое удовольствие писать запросы в стиле lambda expression. Также никто не мешает там где это надо вызвать хранимую процедуру или обратится к СУБД на чистом SQL.
Ссылка на сравнение: http://androidinsider.ru/smartfony/nexus-5-protiv-nexus-5x-test-skorosti-rabotyi.html