Entity Framework VS LINQ to SQL VS ADO.NET с хранимыми процедурами?

Ответ 1

Во-первых, если вы начинаете новый проект, используйте Entity Framework ("EF") - теперь он генерирует намного лучший SQL (больше, чем Linq to SQL) и его легче поддерживать и он более мощный, чем Linq to SQL (" L2S "). Начиная с выпуска .NET 4.0, я считаю Linq to SQL устаревшей технологией. MS открыто заявляет о том, что не будет продолжать разработку L2S.

1) Производительность

Это сложно ответить. Для большинства операций с одним объектом (CRUD) вы найдете примерно эквивалентную производительность со всеми тремя технологиями. Вы должны знать, как работают EF и Linq to SQL, чтобы использовать их в полной мере. Для операций с большими объемами, таких как запросы на опрос, вы можете захотеть, чтобы EF/L2S "скомпилировал" ваш запрос сущности так, чтобы инфраструктуре не приходилось постоянно восстанавливать SQL, или вы можете столкнуться с проблемами масштабируемости. (см. правки)

Для массовых обновлений, когда вы обновляете огромные объемы данных, сырой SQL или хранимая процедура всегда будут работать лучше, чем решение ORM, потому что вам не нужно направлять данные по проводам в ORM для выполнения обновлений.

2) Скорость развития

В большинстве сценариев EF сбрасывает голые SQL/хранимые процессы, когда дело касается скорости разработки. Дизайнер EF может обновлять вашу модель из вашей базы данных по мере ее изменения (по запросу), чтобы вы не столкнулись с проблемами синхронизации между вашим объектным кодом и кодом вашей базы данных. Единственный раз, когда я не рассматриваю использование ORM, это когда вы создаете приложение типа отчетов/панели мониторинга, где вы не выполняете никаких обновлений, или когда вы создаете приложение просто для выполнения операций обслуживания необработанных данных в базе данных.

3) аккуратный/ремонтопригодный код

Руки вниз, EF бьет SQL/Sprocs. Поскольку ваши отношения смоделированы, соединения в вашем коде относительно редки. Отношения сущностей почти очевидны для большинства читателей. Нет ничего хуже, чем переходить от уровня к уровню отладки или через несколько уровней SQL/средний уровень, чтобы понять, что на самом деле происходит с вашими данными. EF очень мощно внедряет вашу модель данных в ваш код.

4) Гибкость

Хранимые процедуры и сырой SQL более "гибки". Вы можете использовать sprocs и SQL, чтобы генерировать более быстрые запросы для нечетного конкретного случая, и вы можете использовать собственные функциональные возможности БД проще, чем с ORM.

5) В целом

Не поддавайтесь ложной дихотомии выбора ORM против хранимых процедур. Вы можете использовать оба в одном приложении, и вам, вероятно, следует. Крупные массовые операции должны идти в хранимых процедурах или в SQL (который на самом деле может вызываться EF), а EF должен использоваться для ваших операций CRUD и большинства ваших потребностей среднего уровня. Возможно, вы решите использовать SQL для написания отчетов. Я предполагаю, что мораль этой истории такая же, как и всегда. Используйте правильный инструмент для работы. Но, судя по всему, EF очень хорош в настоящее время (начиная с .NET 4.0). Потратьте некоторое время на чтение и глубокое понимание этого, и вы с легкостью сможете создавать удивительные высокопроизводительные приложения.

РЕДАКТИРОВАТЬ: EF 5 немного упрощает эту часть с помощью автоматически скомпилированных запросов LINQ, но для работы с большими объемами вам обязательно нужно протестировать и проанализировать, что лучше всего подходит вам в реальном мире. ,

Ответ 2

Хранимые процедуры:

(+)

• Отличная гибкость
• Полный контроль над SQL
• Максимальная доступная производительность

(-)

• Требует знания SQL
• Хранимые процедуры вышли из-под контроля
• Значительное количество "повторяется" при указании одинаковых имен таблиц и полей. Высокий шанс взломать приложение после переименования сущности БД и пропустить некоторые ссылки на нее где-то.
• Медленное развитие

ORM:

(+)

• Быстрое развитие
• Код доступа к данным теперь находится под контролем исходного кода
• Вы изолированы от изменений в БД. Если это произойдет, вам нужно будет обновить модель/сопоставления только в одном месте.

(-)

• Производительность может быть хуже
• Нет или мало контроля над SQL, который производит ORM (может быть неэффективным или хуже глючит). Возможно, нужно вмешаться и заменить его на пользовательские хранимые процедуры. Это сделает ваш код грязным (немного LINQ в коде, немного SQL в коде и/или в БД вне контроля исходного кода).
• Как и любая абстракция, можно создавать разработчиков "высокого уровня", которые понятия не имеют, как это работает под капотом.

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

На этот вопрос нет общего ответа. Это вопрос священных войн. Также зависит от проекта под рукой и ваших потребностей. Подберите, что лучше для вас.

Ответ 3

ваш вопрос в основном O/RM vs hand writing SQL

Использование ORM или простого SQL?

Взгляните на некоторые из других решений O/RM, L2S - не единственный (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

для решения конкретных вопросов:

• Зависит от качества решения O/RM, L2S довольно хорош при создании SQL
• Это обычно намного быстрее, используя O/RM, как только вы выполняете процесс
• Код также, как правило, намного опрятен и удобен в обслуживании
• Прямой SQL, конечно, даст вам больше гибкости, но большинство O/RM могут выполнять все, кроме самых сложных запросов.
• В целом я бы посоветовал пойти с O/RM, потеря гибкости небрежна.

Ответ 4

LINQ-to-SQL - замечательная часть технологии, которая очень проста в использовании и по большому счету генерирует очень хорошие запросы на задний план. LINQ-to-EF планировалось вытеснить его, но исторически было крайне неудобно использовать и создавать гораздо более низкий SQL. Я не знаю текущее состояние дел, но Microsoft пообещала перенести всю доброту L2S в L2EF, так что, возможно, теперь все лучше.

Лично у меня есть страстная неприязнь к инструментам ORM (см. мою диатрибу здесь для деталей), и поэтому я не вижу оснований одобрять L2EF, поскольку L2S дает мне все, что я когда-либо ожидал от уровня доступа к данным. На самом деле, я даже думаю, что функции L2S, такие как сопоставления вручную и моделирование наследования, добавляют совершенно ненужную сложность. Но это только я.; -)

Ответ 5

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

Я взял SQL+ для тест-драйва в небольшом проекте, и это действительно что-то особенное. Вы в основном добавляете то, что составляет комментарии к вашим подпрограммам SQL, и эти комментарии предоставляют инструкции для генератора кода, который затем создает действительно хорошую объектно-ориентированную библиотеку классов на основе фактической подпрограммы SQL. Вроде как структура сущностей в обратном направлении.

Входные параметры становятся частью входного объекта, выходные параметры и наборы результатов становятся частью выходного объекта, а компонент службы обеспечивает вызовы метода.

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