Linq для SQL или Linq для DataSet?

Question

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

Из всего, что я прочитал, я думаю, что есть 2 разных способа взаимодействия с базами данных:

• Linq to SQL
• Linq to DataSet

Теперь продукт, над которым я работаю, не может полагаться на тип базы данных. Например, он может быть развернут с сервером SQL / Oracle.

Теперь мои вопросы:

1. Если я использую Linq to SQL, я застрял только на сервере SQL?
2. Я думаю, что могу использовать Linq to DataSet для SQL-сервера и оракула. Но потеряю ли я что-то (простоту программирования, производительность, надежность и т. Д.), Если я использую Linq для DataSet для SQL-сервера (по сравнению с Linq для SQL-разницы).

Answer 1

Вы правы относительно # 1 - Linq to Sql будет работать только с базами данных SQL Server.

Я бы использовал ADO Entity Framework, если вам нужна возможность доступа к разным источникам данных (с использованием разных провайдеров). Вы получаете аналогичную гибкость с точки зрения использования POCO-подобных объектов, и ее довольно легко расширить для более сложных / сложных реализаций.

В моем текущем проекте мы используем Linq to Sql, и это было нормально, но нам пришлось преодолеть ряд проблем. Я нашел это слишком упрощенным с точки зрения расширяемости. Я написал (лучше) ответ, касающийся Linq для Sql и Entity Framework здесь .

Относительно вопроса № 2 - я не уверен, что хотел бы вернуться к DataSets. ИМХО, они больше в прошлом, но могут быть полезны, если у вас есть приличный инструментарий с конкретными элементами управления (например, Infragistics). Однако я считаю, что их накладные расходы слишком дороги для быстрых транзакционных систем. Реализация не имеет половины функциональности Linq to Sql или Entity Framework.

Answer 2

Чтобы ответить на ваш первый вопрос: нет, существуют другие реализации linq-провайдеров для oracle, например:

LinqToOracle

DbLinq

Последний поддерживает больше баз данных, например SqLite.

Также ознакомьтесь с ADO.NET Entity Framework .

Answer 3

1. Да, это только SQL Server. Кроме того, Microsoft заморозила L2S и не будет дорабатывать его дальше. Но это хороший фреймворк, он очень хорошо работает и прост в использовании.
2. Linq to DataSet обращается к наборам данных как перечислимым после того, как данные были извлечены из БД. Linq to SQL использует IQueriable для создания динамических запросов SQL. Во многих случаях L2S будет работать намного лучше и вообще избавит вас от написания кода БД.

Вы должны заглянуть в Linq to Entities. Это самый полноценный из доступных каркасов. Сейчас это в основном для SQL Server, но у вас будет поддержка Oracle и т. Д. Вовремя.

Answer 4

1. Вы не привязаны только к серверу SQL. Теоретически вы можете создать провайдера linq для любой базы данных. Есть проект на codeplex для Linq to Oracle http://www.codeplex.com/LinqToOracle. Я сам не пробовал.

2. Как вы получите данные в наборе данных? Я не думаю, что вы собираетесь собрать всю таблицу в набор данных? Это было бы серьезной проблемой производительности. Если вы собираетесь использовать Linq для набора данных, вам нужно будет написать все SQL-запросы самостоятельно, чтобы получить данные из базы данных, вместо того, чтобы позволить linq создавать SQL-запросы. Таким образом, вам сначала придется запросить базу данных, а затем запросить набор данных. Мне кажется, что это двойная работа ...

Answer 5

Вы не привязаны только к SQL Server. Мы предлагаем реализации LINQ to SQL для серверов Oracle, MySQL, PostgreSQL и SQLite. Получить более подробную информацию здесь DataSets не так удобны по сравнению с технологией LINQ to SQL. Проверьте опцию Entity Framework в качестве альтернативы. Вы можете написать несколько моделей хранения для одной концептуальной модели, а затем параллельно использовать базы данных SQL Server и Oracle.

Answer 6

Насколько я знаю, когда вы используете Linq to SQL, вы сильно застряли в SQL Server.

Если вы используете Linq для DataSet, вы потеряете немного простоты программирования: с Linq вы можете использовать сущности Linq напрямую, в то время как с DataSets вы должны продолжать использовать имя DataSet (MyDataSet.Entity = new MyDataSet .Entity ()), который через некоторое время стареет. Я думаю, что это единственная жертва.

Однако вы можете использовать его, например, с Oracle (сделал это на проекте). Это также в значительной степени перетаскивание с немного большим контролем над DataAdapter (насколько я знаю - мне никогда не приходилось так сильно настраивать Linq-to-SQL), вы можете указать (например), какие запросы использовать и т. д.

Поскольку вы по-прежнему можете определять отношения между таблицами в DataSets, вы все равно можете использовать Linq достаточно хорошо, так что проблем там не будет.

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