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](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) ) вы найдете примерно одинаковую производительность со всеми тремя технологиями. Вы должны знать, как работают 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](https://docs.microsoft.com/archive/blogs/efdesign/auto-compiled-linq-queries-entity-framework-june-2011-ctp) , но для работы с большими объемами вам определенно нужно будет протестировать и проанализировать, что лучше всего подходит вам в реальном мире.