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


430

Как бы вы оценили каждый из них с точки зрения:

  1. Представление
  2. Скорость развития
  3. Аккуратный, интуитивно понятный и понятный код
  4. гибкость
  5. В целом

Мне нравится мой SQL, и поэтому я всегда был преданным поклонником ADO.NET и хранимых процедур, но недавно я поиграл с Linq to SQL и был поражен тем, как быстро я записывал свой слой DataAccess и решил потратить когда-нибудь действительно разбираешься в Linq to SQL или EF ... или нет?

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

Обновление: Можете ли вы сосредоточиться на EF VS L2S VS SP, а не ORM VS SP. Меня в основном интересует EF VS L2S. Но я также хотел бы сравнить их с хранимыми процессами, поскольку я знаю много о простом SQl.


94
неконструктивно и все же так много возражений? ...;)
BritishDeveloper

34
Я не понимаю, почему кто-то отметил это неконструктивно. Мне кажется, это действительно хорошо. +1 от меня.
Танюшка

10
Это отличный вопрос, на мой взгляд. Лично я заметил, что Entity Framework и все подобные ORM работают медленнее по сравнению с простым / простым кодом ADO.Net. Я сделал этот тест 2 года назад, а затем снова неделю назад. Я не уверен, как LINQ to SQL сравнивается с EF. Но ADO.Net всегда будет лучшим по производительности. Если вы хотите сэкономить время разработчиков, то Entity Framework является хорошим инструментом, но определенно не тогда, когда производительность является вашей главной задачей.
Сунил

2
@Timeless: существует тенденция не полагаться на механизмы баз данных. Каждый движок базы данных имеет свой собственный язык хранимых процедур, поэтому необходимо дополнительное обучение. 99,9% разработчиков могут положиться на ORM, которые генерируют неплохой код и автоматически создают SQL. Разница в производительности незначительна в случае простого CRUD. Хранимые процедуры сложнее разрабатывать и поддерживать. Несколько лет назад, когда не было ORM и ничего не было сгенерировано магическим и автоматически из базы данных. Написание SP считалось не таким трудоемким, поскольку это было альтернативой написанию операторов SQL в приложении.
LukLed

4
@ Сунил правильно, хотя и недостаточно многословно. Проблема в том, что все думают, что их главной заботой является производительность приложения. Когда я говорю о приложениях, которые требуют высочайшей производительности, я имею в виду хардкорные C ++ MMO или большие объемы транзакций с базами данных, ориентированными на клиентов, с большими миллионами. Вы действительно должны сосредоточиться на объектно-ориентированных принципах, таких как удобство обслуживания , удобочитаемость , постоянное невежество и разделение логики домена . Особенно, когда повышение производительности незначительно в лучшем случае или вообще отсутствует во многих случаях.
Суамер

Ответы:


430

Во-первых, если вы начинаете новый проект, используйте 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 , но для действительно большого объема вам определенно нужно будет протестировать и проанализировать то, что подходит вам лучше всего в реальном мире.


35
Абсолютно блестящий ответ. Сейчас я действительно использую EF для быстрой разработки приложения. Если производительность становится проблемой, хранимые процедуры будут введены для рефакторинга плохо выполняющихся запросов EF. Спасибо!
BritishDeveloper

17
@BritishDeveloper: Кроме того, не забывайте о силе использования представлений. Мы добились большого успеха с определением пары представлений в наших проектах L2S и их использованием там, где, по-видимому, фреймворк пишет плохие запросы. Таким образом, мы получаем все преимущества использования инфраструктуры со всеми преимуществами написания нашего собственного SQL.
Дэйв Маркл

5
Я также использую Представления;) Больше как обходной путь для не перекрестного ограничения БД EF. Хорошая идея для использования для оптимизации, хотя. Спасибо
BritishDeveloper

5
Определенно отличный ответ. Просто хотел добавить наблюдение, которое я имел в своем собственном опыте с L2S против EF4. Поменялись местами с L2S -> EF4 после того, как мы поняли, что мы можем использовать несколько разных RDMBS ... но, все еще работая на MSSQL, падение производительности в основном проявлялось в области графического интерфейса моего приложения. Привязка данных к набору результатов в L2S была намного быстрее, чем в EF4. Это точно такой же запрос в той же БД. Здесь нужно отметить одну вещь: я возвращаю записи с 90k +, поэтому разница была довольно очевидной. Может на небольших комплектах это не проблема? Не уверен, как он будет масштабироваться, хотя на сайтах с большим
объемом

5
Хороший ответ. Я только что провел 4 недели, работая с LINQ-to-Entities, пытаясь втиснуть в него все, прежде чем окончательно понял, что вам нужен собственный SQL для таких вещей, как массовое копирование, массовое удаление, сверхбыстрое удаление дубликатов из базы данных и т. Д. Используйте правильный инструмент для работы, нет ничего постыдного в смешивании нативного SQL с каркасом LINQ to Entities.
Contango

93

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

(+)

  • Большая гибкость
  • Полный контроль над SQL
  • Высочайшая производительность

(-)

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

ORM:

(+)

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

(-)

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

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

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


47
Я не думаю, что вопросы, касающиеся контроля источников, актуальны. Схема базы данных, хранимые процедуры, пользовательские функции и т. Д. Могут быть и должны находиться под контролем источника.
Ли Ганн

15
+1 заAs any abstraction can produce "high-level" developers having no idea how it works under the hood
nawfal

3
Согласен, аргумент управления исходным кодом неверен. Мы всегда храним наши сценарии создания базы данных в SVN. Как вы можете даже сохранить базу данных вне контроля исходного кода при разработке приложения базы данных?
Wout

3
EF на самом деле не подходит для высокой доступности и высокой производительности, я не администратор баз данных, но я не вижу, что предлагает EF, что облегчает кодирование.
Джейми

4
Таким образом, мы отказываемся от гибкости, полного контроля и производительности для «быстрой разработки» и избегаем изменений кода при изменении БД. Звучит как чистая лень для меня.
user2966445

18

ваш вопрос в основном O / RM против написания руки SQL

Используя ORM или простой SQL?

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

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

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

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

@ Дэвид Спасибо, но это не ORM против SQL. Я с нетерпением жду перехода на ORM, и мне интересно, на что потратить время на обучение: EF или L2S (если они не являются мусором по сравнению с хранимыми процессами)
BritishDeveloper

1
Я бы определенно сказал, что они не мусор по сравнению с хранимыми процессами, и побочным преимуществом является то, что вы не распространяете код в базе данных. Лично мне нравится L2S, но я мало что сделал с EF на данный момент, и кажется, что L2EF собирается вытеснить его, поэтому я бы пошел на EF. Кроме того, как только вы идете Linq, вы не возвращаетесь.
BlackICE

13

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

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


1
L2S довольно хорош, но имеет недостаток, который Microsoft заявил, что они в основном не собираются вкладывать большие средства в его расширение. Вы можете увидеть результаты этого уже в последней версии, которая имеет только несколько исправлений ошибок и некоторую поддержку типов данных SQL Server 2008.
FinnNk

Согласен, @FinnNk. Прискорбно, что использование L2S несколько рискованно из-за статуса парии. Но если бы они действительно полностью отказались от него в пользу L2EF, я сильно подозреваю, что будет путь миграции, потому что он все еще имеет смысл.
Марсело Кантос

3
Линк к EF созрел, и теперь производит SQL так же хорошо, как L2S (начиная с .NET 4.0). В настоящее время L2EF намного лучше, чем L2S, поскольку он, по крайней мере, может обновлять вашу модель по мере изменения БД, что L2S никогда не сможет сделать автоматически. Мне также нравится тот факт, что вы можете отобразить простые отношения M: M с EF как отношения без необходимости иметь промежуточную сущность. Это делает код намного чище.
Дэйв Маркл,

2
Спасибо за обновление @Dave. Однако я не согласен с комментарием M: M. Схемы, с которыми я работал, почти всегда увеличивают дополнительные атрибуты в таблицах соединений. Это вызывает структурные изменения в объектной модели, требующие много переделки кода. Я бы предпочел иметь дело с промежуточным отношением явно с самого начала.
Марсело Кантос

1

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.