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

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

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.

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

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

(+)

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

(-)

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

ORM:

(+)

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

(-)

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

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

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

ваш вопрос в основном 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, потеря гибкости незначительна

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

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

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

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

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

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