Linq to SQL 还是 Linq to DataSet？
我是 Linq 世界的新手，目前正在探索它。 我正在考虑在我的下一个涉及数据库交互的项目中使用它。
根据我所读到的内容，我认为有两种不同的方式与数据库交互：
- Linq to SQL
- Linq to DataSet
现在我要开发的产品不能依赖于数据库的类型。 例如，它可能与 SQL Server/Oracle 一起部署。
现在我的问题是：
- 如果我使用 Linq to SQL，我是否只能使用 SQL Server？
- 我想我可以将 Linq to DataSet 用于 SQL Server 和 Oracle。 但是，如果我使用 Linq to DataSet for SQL Server（与 Linq to SQL offcourse 相比），我会失去一些东西（易于编程、性能、可靠性等）。
I am new to Linq world and currently exploring it. I am thinking about using it in my next project that involves database interaction.
From whatever I have read, I think there are 2 different ways to interact with databases:
- Linq to SQL
- Linq to DataSet
Now the product that I am to work on, cannot rely on the type of database. For example, it might be deployed with SQL server/Oracle.
Now my questions are:
- If I use Linq to SQL, am I stuck with SQL server only?
- I think I can use Linq to DataSet for both SQL server and oracle. But will I loose something (ease of programming, performance, reliability etc) if I use Linq to DataSet for SQL server (compared to Linq to SQL offcourse).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
关于#1，您是正确的 - Linq to Sql 只能针对 SQL Server 数据库工作。
如果您希望能够访问不同的数据源（使用不同的提供程序），我会选择 ADO 实体框架。 您在使用类似 POCO 的实体方面获得了类似的灵活性，并且很容易扩展以实现更高级/复杂的实现。
在我当前的项目中，我们使用 Linq to Sql，效果很好，但我们有许多问题需要克服。 我发现它在可扩展性方面有时有点过于简单化。 我写了一个关于 Linq to Sql 和实体框架的（更好的）回复 这里。
关于问题#2 - 我不确定我是否想回到数据集。 恕我直言，它们已经成为过去，但如果您有一个带有特定控件的不错的工具包（例如 Infragistics），它们可能会很有用。 然而，我发现它们的开销对于快速事务系统来说太昂贵了。 该实现不具备 Linq to Sql 或实体框架一半的功能。
You are correct about #1 - Linq to Sql will only work against SQL Server databases.
I'd go with the ADO Entity Framework if you want the ability to access different data sources (using different providers). You get similar flexibility in terms of using POCO-like entities and it's quite easy to extend for more advanced/complex implementations.
On my current project, we're using Linq to Sql and it's been fine, but we've had a number of issues to overcome. I've found it a little too simplistic at times in terms of extensibility. I wrote a (better) response regarding Linq to Sql and the Entity Framework here.
With respect to question #2 - I'm not sure I'd like to go back to DataSets. IMHO they are more a thing of the past, but can be useful if you have a decent toolkit with specific controls (like Infragistics). However, I find their overhead too expensive for fast transactional systems. The implementation doesn't have half the functionality of Linq to Sql or the Entity Framework.
回答你的第一个问题：不，oracle 还有其他 linq 提供程序的实现，例如：
LinqToOracle
DbLinq
后者支持更多数据库，例如 SqLite。
另请查看 ADO.NET 实体框架。
To answer your first question: no, there are other implementations of linq providers for oracle, for example:
LinqToOracle
DbLinq
The latter supporting more databases, like SqLite.
Also checkout the ADO.NET Entity Framework.
您应该研究 Linq to Entities。 这是目前最成熟的框架。 目前，它主要针对 SQL Server，但很快就会支持 Oracle 等。
You should look into Linq to Entities. That's the most full-blown framework available. Right now, it's mainly for SQL Server, but you will have support for Oracle etc. in time.
您不仅仅局限于 SQL Server。 理论上，您可以为任何数据库构建 linq 提供程序。 Codeplex 上有一个针对 Linq to Oracle 的项目 http://www.codeplex.com/LinqToOracle。 我自己没有尝试过。
如何将数据放入数据集中？ 我不认为您要将整个表提取到数据集中？ 这将是一个严重的性能问题。 如果要使用 Linq to dataset，则需要自己编写所有 SQL 查询以从数据库获取数据，而不是让 linq 创建 SQL 查询。 因此，您实际上首先必须查询数据库，然后查询数据集。 对我来说似乎是双重工作...
You are not stuck with SQL server only. In theory you can build a linq provider for any database. There is a project on codeplex for Linq to Oracle http://www.codeplex.com/LinqToOracle. I have not tried it myself.
How will you get the data into the dataset? I don't suppose you are going to fetch an entire table into a dataset? That would be a serious performance problem. If you are going to use Linq to dataset you will need to write all the SQL queries yourself to get the data from the database, instead of letting linq create the sql queries. So you will actually first have to query the database and then query the dataset. Seems like double work to me...
据我所知，当您使用 Linq to SQL 时，您几乎会被 SQL Server 困住。
如果您使用 Linq to DataSet，您将失去一点编程的便利性：使用 Linq，您可以直接使用 Linq 实体，而使用 DataSet，您必须继续使用 DataSet 名称 (MyDataSet.Entity = new MyDataSet.Entity( ))，一段时间后就会变旧。 我认为这是唯一的牺牲。
但是，您可以将它与 Oracle 等一起使用（在项目中就是这样做的）。 它也几乎是拖放操作，对 DataAdapter 有更多的控制（据我所知 - 我从来没有必要对 Linq-to-SQL 进行那么多调整），您可以指定（例如）要使用哪些查询等等。
由于您仍然可以定义 DataSet 中表之间的关系，因此您仍然可以很好地使用 Linq，因此您不会真正看到问题。
我认为 Linq-to-DataSet 的可靠性与 Linq-to-SQL 一样好（从未出现过问题），性能似乎足够好，但永远无法真正分析它。
When you use Linq to SQL, you'd be pretty much stuck with SQL Server, as far as I know.
If you use Linq to DataSet, you'll lose a bit of ease of programming: With Linq, you can use the Linq entities directly while with DataSets, you have to keep using the DataSet name (MyDataSet.Entity = new MyDataSet.Entity()), which gets old after a while. I think that that's the only sacrifice.
However, you can use it with e.g. Oracle (did that on a project). It's also pretty much drag-and-drop with a bit more control on the DataAdapter (as far as I know - I've never had to tweak Linq-to-SQL that much), you can specify (e.g.) which queries to use, etc.
Since you can still define relationships between tables in DataSets, you can still use Linq well enough, so you won't really see problems there.
I assume that reliability is as good with Linq-to-DataSet as with Linq-to-SQL (never had problems), performance seemed to be good enough, never could really profile it, though.
您不仅仅局限于 SQL Server。
我们为 Oracle、MySQL、PostgreSQL 和 SQLite 服务器提供 LINQ to SQL 实现。
在此处获取更多信息
与 LINQ to SQL 技术相比，DataSet 并不那么方便。
查看实体框架选项作为替代方案。
您可以使用一个概念模型编写多个存储模型，然后并行使用 SQL Server 和 Oracle 数据库。
You are not stuck to SQL Server only.
We offer LINQ to SQL implementations for Oracle, MySQL, PostgreSQL, and SQLite servers.
Get more information here
DataSets are not so convenient in comparison with LINQ to SQL technology.
Check out the Entity Framework option as an alternative.
You are able to write several storage models with one conceptual model and then use SQL Server and Oracle database in parallel.