Разница между Linq и Sql, Linq, типизированные наборы данных, ADO.NET

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

Итак, когда я принимал курс ASP.NET, который был частью моей программы.

Сначала нам понравился ADO.NET, где мы просто написали все с помощью операторов SQL в коде. Затем мы перешли на трехуровневую архитектуру. Это было сделано путем создания классов и создания наборов данных, которые возвращают материал.

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

Затем я нашел на сайте Asp.net свой учебник из 3-х ярусной арки, который мне очень понравился. Они используют типизированные наборы данных. Вы добавляете файл набора данных в свою папку DAL, и вы будете делать таблицы адаптеров и прочее через графический интерфейс. Затем вы напишете код в этом графическом интерфейсе, я нашел его идеальным решением, так как теперь мой код SQL был удален от моего кода, и мне не пришлось беспокоиться о котировках, и все это не было правильным или закрывало соединения и прочее плюс это даже имел построитель GUI SQL!

Тогда я просто сделаю файл в папке BLL и создам свойство, чтобы захватить адаптер таблицы и написать логику бизнес-уровня.

Единственное, что мне не понравилось, это то, что оно было напечатано, если мои вещи попытались вернуть несколько новых строк, они разозлились.

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

Теперь их так много.

  • Linq → то, что сказали некоторые люди, заменит ADO.NET, а некоторые сказали, что это не так.
  • Linq to sql
  • ado.net

Я не уверен, что это все из них, вероятно, нет.

Прежде чем писать этот пост, я быстро проверил, что такое linq для sql, и увидел некоторые сообщения о том, что MS убивает его. Они, где с 2008 года, поэтому я не знаю, верно это или нет, но я заметил, что почти все книги MVC используют как linq для sql, поэтому я не думаю, что это так.

Так стоит ли переключать на что-то другое, а затем набирать наборы данных? Или каждый используется для разных ситуаций?

ОТВЕТЫ

Ответ 1

LINQ сам по себе является базовой технологией ( "Language Integrated Query" ), запеченной в С# 3.0 - она ​​имеет ничего, чтобы делать сама по себе с базами данных. LINQ может использоваться для различных целей: базы данных, XML, объекты в памяти, сущности Entity Framework, Active Directory - вы называете это.

Linq-To-SQL - это легкая и простая технология MS-SQLServer, позволяющая легко и просто использовать таблицы SQL Server как реальные объекты в вашем приложении .NET. Это "объектно-реляционный картограф", который упрощает работу с базами данных. Это только SQL Server, и Microsoft не будет расширять его гораздо дальше - он доступен, также в .NET 4.0, но больше не будет развиваться.

ADO.NET - это базовая технология доступа к данным в .NET - она ​​дает вам доступ к широкому спектру хранилищ данных, реляционных и нереляционных. Это самая простая технология - вы обрабатываете свои данные очень низкоуровневым образом.

Кроме того, у вас есть наборы данных ADO.NET, которые немного похожи на Linq-to-SQL, поскольку они упрощают работу с базами данных. В отличие от Linq-to-SQL, вы не имеете дело с объектами из вашей модели домена в вашем коде .NET, но вместо этого вы имеете дело с ориентированными на базу данных строками и столбцами, как они существуют в базе данных. Это более прямое представление о том, что в базе данных оно находится на более низком уровне, оно очень тесно связано с вашим макетом базы данных, и оно не является "приятным" и удобным в использовании как объекты Linq-To-SQL - вы имеете дело с строками низкого уровня и столбцы и их значения.

Если у вас есть выбор прямо сейчас и вам не нужно ничего, кроме SQL Server, я бы очень рекомендовал проверить Linq-to-SQL - сопоставление из необработанных таблиц базы данных с красивыми и простыми в использовании .NET-объектами делает вашу жизнь намного проще!

Марк

Ответ 2

Чтобы прояснить историю LINQ-to-SQL; он не "мертв" - это полностью поддерживаемая часть платформы .NET и находится в активной разработке (в Redmond есть команда LINQ to SQL).

Дело в том, что разработка новой функции в основном происходит в EF, включая (надеюсь) преодоление разрыва между LINQ-to-SQL (который, как правило, очень популярен) и EF (который был критикуется во многих отношениях).

Например, EF в 4.0 поддерживает объекты POCO, такие как LINQ-to-SQL.

Лично я все еще поклонник LINQ-to-SQL и с удовольствием использую его для новых сборок, но я бы спрятал все это за интерфейсом репозитория, чтобы я мог поменять его по своему усмотрению любому инструменту

  • raw ADO.NET
  • LINQ к SQL
  • NHibernate
  • LLBLGenPro
  • Entity Framework

Единственное, что я не касался: DataSet;-p

Ответ 3

Я бы сказал, что если у вас возникли проблемы с получением котировок прямо в ваших операторах SQL с использованием ADO.NET, вы, вероятно, будете строить SQL-запросы не по-другому. Склонный к SQL-инъекция или, по крайней мере: беспорядочный код.

LINQ to SQL использует ADO.NET для выполнения этой задачи. Это комбинация Object-relational mapping (ORM) в сочетании с новым синтаксисом запроса в основном. Я бы не стал инвестировать время в LINQ to SQL, поскольку Microsoft объявила о завершении жизни.

Entity Framework - это замена LINQ to SQL. Это инструмент ORM, который поставляется с собственным SQL, например языком запросов, Entity SQL. Вы можете использовать LINQ поверх него, так что большинство простых запросов в точности совпадают с LINQ to SQL.

Какой метод использовать во многом зависит от того, что вы пытаетесь сделать. Я бы не использовал типизированные DataSets (или любые DataSets). Я полагаю, это личное предпочтение, но если вы можете создавать типизированные DataSets, вам лучше делать полномасштабное объектно-реляционное сопоставление.

Знание базового ADO.NET - полезное умение, однако вы смотрите на него. Особенно, если вам нужно обновить несколько записей в базе данных без предварительного извлечения этих данных, вы всегда будете писать инструкции SQL. Я бы рекомендовал создавать хранимые процедуры для тех случаев, которые вы можете вызывать с помощью простого ADO.NET, или вы можете добавить их в свою модель в Entity Framework и вызвать их там.

Entity Framework дает вам некоторую независимость от базы данных (в отличие от LINQ to SQL). Для Oracle существуют реализации, но у меня нет опыта с ними лично. Из того, что я слышал, они налагают некоторые нежелательные ограничения, если вы выполняете полууложную работу.