Какая "лучшая" структура/подход к доступу к данным для С# и .NET?

(EDIT: я сделал его вики-сообществом, поскольку он больше подходит для совместного формата.)

Существует множество способов доступа к SQL Server и другим базам данных из .NET. У всех есть свои плюсы и минусы, и это никогда не будет простым вопросом, который является "лучшим" - ответ всегда будет "это зависит".

Однако я ищу сравнение на высоком уровне различных подходов и фреймворков в контексте разных уровней систем. Например, я бы предположил, что для быстрого и грязного приложения Web 2.0 ответ будет сильно отличаться от внутреннего CRUD-приложения Enterprise.

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

Пока это мое понимание на высоком уровне, но я уверен, что это неправильно... В первую очередь я уделяю основное внимание подходам Microsoft, чтобы это сфокусировалось.

ADO.NET Entity Framework

Агностик базы данных
Хорошо, потому что он позволяет обменивать входы и выходы
Плохо, потому что это может повлиять на производительность, и поставщики баз данных не слишком довольны этим.
Кажется, это предпочтительный маршрут MS для будущего.
Сложно учиться (см. 267357)
Доступ к нему осуществляется через LINQ to Entities, поэтому он предоставляет ORM, что позволяет абстрагироваться в вашем коде

LINQ to SQL

Неопределенное будущее (см. Действительно ли LINQ to SQL мертв?)
Легко учиться (?)
Работает только с MS SQL Server
См. также Плюсы и минусы LINQ

"Стандарт" ADO.NET

Нет ORM
Нет абстракции, поэтому вы вернетесь к "рулонам" и играете с динамически созданным SQL
Прямой доступ, позволяет потенциально повысить производительность
Это связано с вековой дискуссией о том, следует ли сосредоточиться на объектах или реляционных данных, на которые, естественно, отвечает "это зависит от того, где основная часть работы", и поскольку это непрошенный вопрос, мы надеемся, что мы не нужно вдаваться в это слишком много. ИМХО, если ваше приложение в основном управляет большими объемами данных, не имеет смысла слишком сильно абстрагировать его на объекты в интерфейсном коде, вам лучше использовать хранимые процедуры и динамический SQL, чтобы выполнить такую большую работу, как возможно на задней панели. Принимая во внимание, что если вы в первую очередь взаимодействуете с пользователем, что вызывает взаимодействие с базами данных на уровне десятков или сотен строк, ORM имеет смысл. Итак, я полагаю, что мой аргумент в пользу хорошего старомодного ADO.NET был бы в том случае, когда вы манипулируете и изменяете большие массивы данных, и в этом случае вы получите прямой доступ к бэкэнд.
Другим случаем, конечно, является то, где вы должны получить доступ к устаревшей базе данных, которая уже охраняется хранимыми процедурами.

Элементы управления источником данных ASP.NET

Являются ли они чем-то совершенно иным или просто слоем над стандартным ADO.NET? - Вы действительно использовали бы их, если бы у вас был DAL, или если вы реализовали LINQ или Entities?

NHibernate

Кажется, это очень мощный и мощный ORM?
Открытый исходный код

Некоторые другие релевантные ссылки; NHibernate или LINQ to SQL Entity Framework vs LINQ to SQL

Ответ 1

Я думаю, что 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.

Ответ 2

Проработав 20+ разных проектов С#/ASP.NET, я всегда получаю NHibernate. Я часто начинаю с совершенно другого стека - ADO.NET, ActiveRecord, ручного проката. Существует множество причин, по которым NHibernate может работать в самых разных ситуациях, но для меня абсолютно важно сохранение во времени, особенно когда оно связано с генерированием кода. Вы можете изменить datamodel, и сущности будут восстановлены, но большинство/весь другой код не нужно изменять.

У MS есть неприятная привычка продвигать технологии в этой области, которые параллельны существующему открытому исходному коду, а затем отбрасывают их, когда они не вылетают. Кто-нибудь помнит объекты ObjectSpaces?

Ответ 3

Добавлен для новых технологий:

С выпуском 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 феноменальна, и вы не получите ничего, если вы выберете другую СУБД.

Ответ 4

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

Недавно я сделал веб-приложение в MVC2, где я выбрал ADO Entities Framework, и я все время использую Linq.

Я должен сказать, меня впечатлила скорость! и на нашем сайте было около 35 000 уникальных посетителей в день, со скоростью около 60 ГБ в день (я резко сократил этот номер 60 Гбит, разместив все статические файлы в Amazon S3 - отличная .NET-оболочка, которую они должны сказать).

Я всегда буду идти таким образом. Легко начать (просто добавьте новый элемент данных, выберите таблицы и его! Для каждого изменения в базе данных, нам просто нужно обновить модель, сделанное автоматически всего за 2 клика), и это весело использовать - правила Linq!