linq to sql vs ado.net - 打开连接方面的性能
我必须从表（大约 40 列）中获取记录，处理每条记录，调用该记录上的 Web 服务，等待其响应并将记录更新到数据库。
现在，我看到两个选择。
<强> 1.Linq 到 Sql
<强> 2.带有类型化数据集的ADO.Net
（我将 DataReader 的选项留给我必须做的所有额外工作。）
2 在获取数据后立即关闭连接，我可以离线处理数据并稍后提交更改，即，我没有保持连接打开，所以长的。 1，为了能够在最后提交更改，我必须始终保持连接打开。
您认为每当经过一定时间的处理后需要提交更改时，2 总是最好的方法还是我遗漏了一些东西？
I have to get records from a table(about 40 columns), process each record, call a web service on this record, wait for its response and update the record to database.
Now, I see 2 options.
1. Linq to Sql
2. ADO.Net with Typed Dataset
(I leave the option of DataReader for all the extra work I have to do.)
2 closes the connection soon after fetching the data, I can process data offline and submit changes later, i.e, I don't have keep connection open for so long. With 1, in-order to be able to submit changes at the end, I have to keep the connection open all the time.
Do you think 2 is the always the best way whenever changes need to submitted after a certain period of processing or am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您使用获取的对象时，Linq to SQL 或 Entity Framework 都不会保持连接打开。如果您想利用各种上下文的更改跟踪功能，则需要将上下文对象保留在范围内，但这并不意味着与数据库的连接在此期间保持打开状态。实际上，仅当您迭代结果（数据绑定）以及调用 SubmitChanges/SaveChanges 时，连接才会打开。否则连接将关闭。
这些技术在幕后使用 ADO.Net DataReaders 和命令对象。仍然没有像 VB6 时代那样的打开游标的概念。
Neither Linq to SQL or Entity Framework keep the connection open while you are working with the fetched objects. If you want to take advantage of the change tracking capabilities of the various contexts, you need to keep the context object in scope, but that doesn't mean the connection to the database remains open during that period. In actuality, the connection is only open while you are iterating on the results (databinding) and when you call SubmitChanges/SaveChanges. Otherwise the connetion is closed.
These technologies use ADO.Net DataReaders and command objects under the covers. There's still no concept of open cursors like you had back in the VB6 days.
L2S 或实体框架会带来一些开销，但说实话，您节省的时间是非常值得的，每当您对对象执行 Linq 查询时，SQL 都会为您进行优化。
普通的旧 ADO.Net 是老派 - Linq 是现在的出路。
L2S or Entity Framework introduce a bit of overhead, but honestly the time you save is well worth it and whenever you perform a Linq query on your objects the SQL is optimized for you.
Plain old ADO.Net is old school - Linq is the way to go now.
微软迎合新手，并将自己作为“业余爱好者”语言推销给大众。
LINQ 允许开发人员查询没有业务访问数据源的数据源。
拥有深厚的知识和足够的大脑来编写自己的优化 T-SQL 也许是一项令人向往的技能，而不是可笑的“老派”。
作为一名软件工程师，一个人应该朝着编写能够尽可能高效、快速执行的软件的方向发展。选择更高级别的构造的整个“节省开发时间”的论点是因为它实现起来太简单了，这表明如果与高级工程师版本一起堆叠，该程序将执行多么糟糕。
不要被那些让编码“更快”的最新、最好的产品所吸引。如果您足够聪明，可以自己做，那就自己做，避免让 LINQ 语法为您编写 T-SQL。
在商业世界中，微秒至关重要，当您的软件需要以您知道如何制作的速度运行时，成为公司的宝贵商品将考验您的深厚知识。
简而言之，知识渊博永远不会过时。
Microsoft caters to newbies and sells itself to the masses as a "hobbyist" language.
LINQ allows developers to query a datasource who have no business accessing a data source.
Having deep knowledge and a brain enough to write your own optimized T-SQL is perhaps is a desireable skill, not laughable as, "old school".
As a software engineer a person should move in the direction of writing software which can perform as efficient and fast as possible. The whole "saving development time" argument for choosing a higher level construct because it is all too simple to implement speaks to how crappy the program will perform if stacked up next to a senior engineers version.
Don't get sold on latest and greatest offerings that make coding "faster". If you are smart enough to do it yourself, then do it yourself and avoid having a LINQ syntax write T-SQL for you.
There is a measure of scale in the business world where microseconds count, and being a valuable commodity to a company will put your deep knowledge to the test when your software needs to run as fast as you know how to make it.
In short, it is never out of style to have deep knowledge.