Какова "лучшая" структура доступа к данным для C # и .NET? - PullRequest
27 голосов
/ 18 марта 2009

(РЕДАКТИРОВАТЬ: я сделал это вики сообщества, так как он больше подходит для совместного формата.)

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

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

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

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

ADO.NET Entity Framework

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

LINQ to SQL

«Стандарт» ADO.NET

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

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

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

NHibernate

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

Некоторые другие соответствующие ссылки; NHibernate или LINQ to SQL Entity Framework против LINQ to SQL

Ответы [ 4 ]

6 голосов
/ 18 марта 2009

Я думаю, что 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, потому что это пустая трата времени. Я всегда иду на ОРМ.

4 голосов
/ 19 января 2017

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

С Microsoft Sql Server для Linux в бета-версии прямо сейчас, я думаю, можно не быть независимым от базы данных. .Net Core Path и маршрут MS-SQL позволяют вам работать на серверах Linux, таких как Ubuntu, полностью без оконных зависимостей.

Как таковой, по моему мнению, очень хорошим ходом является не использование полной структуры ORM или элементов управления данными и использование возможностей SSDT Visual Studio Projects (Sql Server Data Tools) и Micro ORM.

В Visual Studio вы можете создать Sql Server Project в качестве легального проекта Visual Studio. Это позволяет вам создать всю базу данных с помощью дизайнеров таблиц или редактирования необработанных запросов прямо в Visual Studio.

Во-вторых, вы получаете инструмент сравнения схем SSDT, который вы можете использовать для сравнения вашего проекта базы данных с действующей базой данных в Microsoft Sql Server и обновления. Вы можете синхронизировать ваш проект Visual Studio с сервером, в результате чего обновления в вашем проекте выходят на сервер. Или вы можете синхронизировать сервер с вашим проектом, что приведет к обновлению исходного кода. С помощью этого маршрута вы можете легко получить изменения, сделанные администратором базы данных прошлым вечером в обслуживании, и легко выдвинуть новые изменения в разработке для новой функции с помощью простого инструмента.

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

Теперь для написания кода против вашей базы данных MS-SQL я рекомендую 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 Server. Тем не менее, Microsoft Sql Server, по моему мнению, является одним из лучших RDBM.

У него есть функции DBMail, Jobs, CLR и так далее. Кроме того, интеграция между Visual Studio и сервером MS-SQL является феноменальной, и вы ничего не получите, если выберете другую СУБД.

4 голосов
/ 18 марта 2009

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

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

1 голос
/ 25 декабря 2010

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

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

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

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

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