(EDIT: я сделал его вики-сообществом, поскольку он больше подходит для совместного формата.)
Существует множество способов доступа к SQL Server и другим базам данных из .NET. У всех есть свои плюсы и минусы, и это никогда не будет простым вопросом, который является "лучшим" - ответ всегда будет "это зависит".
Однако я ищу сравнение на высоком уровне различных подходов и фреймворков в контексте разных уровней систем. Например, я бы предположил, что для быстрого и грязного приложения Web 2.0 ответ будет сильно отличаться от внутреннего CRUD-приложения Enterprise.
Я знаю, что есть множество вопросов о переполнении стека, связанных с подмножествами этого вопроса, но я думаю, было бы полезно попытаться построить итоговое сравнение. Я постараюсь обновить вопрос с исправлениями и разъяснениями по мере продвижения.
Пока это мое понимание на высоком уровне, но я уверен, что это неправильно... В первую очередь я уделяю основное внимание подходам Microsoft, чтобы это сфокусировалось.
Являются ли они чем-то совершенно иным или просто слоем над стандартным ADO.NET? - Вы действительно использовали бы их, если бы у вас был DAL, или если вы реализовали LINQ или Entities?
Некоторые другие релевантные ссылки; NHibernate или LINQ to SQL Entity Framework vs LINQ to SQL
Я думаю, что LINQ to SQL хорош для проектов, предназначенных для SQL Server.
ADO.NET Entity Framework лучше, если мы ориентируемся на разные базы данных. В настоящее время я думаю, что многие поставщики доступны для ADO.NET Entity Framework, провайдера для PostgreSQL, MySQL, esql, Oracle и многих других (проверьте http://blogs.msdn.com/adonet/default.aspx).
Я больше не хочу использовать стандартный ADO.NET, потому что это пустая трата времени. Я всегда обращаюсь за ORM.
Проработав 20+ разных проектов С#/ASP.NET, я всегда получаю NHibernate. Я часто начинаю с совершенно другого стека - ADO.NET, ActiveRecord, ручного проката. Существует множество причин, по которым NHibernate может работать в самых разных ситуациях, но для меня абсолютно важно сохранение во времени, особенно когда оно связано с генерированием кода. Вы можете изменить datamodel, и сущности будут восстановлены, но большинство/весь другой код не нужно изменять.
У MS есть неприятная привычка продвигать технологии в этой области, которые параллельны существующему открытому исходному коду, а затем отбрасывают их, когда они не вылетают. Кто-нибудь помнит объекты ObjectSpaces?
Добавлен для новых технологий:
С выпуском Microsoft Sql Server для Linux в бета-версии прямо сейчас, я думаю, что не будет агностиком базы данных. Путь .Net Core Path и MS-SQL позволяет запускать на серверах Linux, таких как Ubuntu, полностью без зависимостей Windows.
Таким образом, imo очень хороший поток - не использовать полную структуру ORM или элементы управления данными и использовать возможности проектов SSDT Visual Studio (Sql Server Data Tools) и Micro ORM.
В Visual Studio вы можете создать проект Sql Server как законный проект Visual Studio. Это позволяет вам создавать всю базу данных с помощью дизайнеров таблиц или редактирование необработанных запросов прямо в визуальной студии.
Во-вторых, вы получаете инструмент сравнения схем SSDT, который вы можете использовать для сравнения вашего проекта базы данных с живой базой данных на сервере Microsoft Sql и обновления. Вы можете синхронизировать свой проект Visual Studio с сервером, в результате чего обновления в вашем проекте выходят на сервер. Или вы можете синхронизировать сервер с проектом, чтобы ваш исходный код обновлялся. С помощью этого маршрута вы можете легко подобрать изменения, внесенные администратором базы данных в последнее время, и быстро изменить свои новые разработки для новой функции простым инструментом.
Используя тот же инструмент, вы можете вычислить перенос script, не выполнив его, если вам нужно передать это в отдел операций и отправить заказ на изменение, он работает для этого потока.
Теперь для написания кода против вас MS-SQL Database, я рекомендую PetaPoco.
Потому что PetaPoco работает отлично в сочетании с вышеупомянутым решением SSDT. PetaPoco поставляется с текстовыми шаблонами T4, которые вы можете использовать для генерации всех ваших классов сущностей данных, и создает для вас классы массового уровня данных.
Уловка, вы должны сами писать запросы, что не так уж плохо.
Итак, вы получите что-то вроде этого:
var people = dbContext.Fetch<Person>("SELECT * FROM People where Username Like '%@0%'", "bob");
PetaPoco автоматически обрабатывает параметрирование @0 для вас, он также имеет удобный класс Sql для построения запросов.
Кроме того, PetaPoco на порядок быстрее EF6 и в 8+ раз быстрее, чем EF7.
Таким образом, это решение включает в себя использование SSDT для управления SCHEMA и PetaPoco для интеграции кода с усилением высокой ремонтопригодности, настройки и очень хорошей производительности.
Единственным недостатком этого подхода является то, что вы сильно привязываетесь к серверу Microsoft Sql. Однако, imo, Microsoft Sql Server является одним из лучших RDBM там.
Он получил функции DBMail, Jobs, CLR, и так далее. Кроме того, интеграция между Visual Studio и сервером MS-SQL феноменальна, и вы не получите ничего, если вы выберете другую СУБД.
Я должен сказать, что я никогда не использовал NHibernate в течение огромного времени, которое необходимо было начать использовать... время, потраченное впустую на настройку XML.
Недавно я сделал веб-приложение в MVC2, где я выбрал ADO Entities Framework, и я все время использую Linq.
Я должен сказать, меня впечатлила скорость! и на нашем сайте было около 35 000 уникальных посетителей в день, со скоростью около 60 ГБ в день (я резко сократил этот номер 60 Гбит, разместив все статические файлы в Amazon S3 - отличная .NET-оболочка, которую они должны сказать).
Я всегда буду идти таким образом. Легко начать (просто добавьте новый элемент данных, выберите таблицы и его! Для каждого изменения в базе данных, нам просто нужно обновить модель, сделанное автоматически всего за 2 клика), и это весело использовать - правила Linq!