仅使用 SqlConnection SqlCommand 和 SqlDataReader 进行数据访问层是否可以
我知道现在有很多现成的东西可供您使用，但如果您想完全控制数据库请求/查询并获得最佳性能，我认为这就是正确的选择。另外，由于 ADO.NET 自动为 SqlConnection 进行连接池，您认为如何？
I know that nowadays there is a lot of ready-to-go stuff that you can use, but if you want full control over db requests/queries, and best performance I think that this is the way to go. Also because ADO.NET does the connection pooling automatically for SqlConnection, how do you think ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
绝对地。如果您想要极致的性能，那么没有比这更快的了。我觉得还是可以的。
事实上，我现在正在开发一个使用 SQL、DataReaders 和 SQLConnections 的报告系统，因为它所做的一切都运行 SQL。 OLAP 多维数据集并不是 OR 映射器的最佳候选者。
Absolutely. If extreme performance is what you want, you can't get much faster than this. I think it's still OK.
In fact, I'm doing a reporting system right now which uses SQL, DataReaders, and SQLConnections because all it does it run SQL. OLAP cubes aren't exactly the best candidates for OR mappers.
如果您确实需要完全控制生成的 SQL 查询并寻求最佳性能，那么这就是您的最佳选择。但有时最好的性能是以可读性和可维护性较差的代码为代价的。如果是这种情况，您可能需要决定这个价格是否值得支付。
If you really need full control over the generated SQL queries and are looking for best performance this is the way to go. But sometimes the best performance comes at the cost of less readable and less maintainable code. If this is the case you might need to make a decision whether this price is worth paying.
如果您需要最佳性能，那就没问题。它为您提供更多控制和更好的性能。顺便说一下，这里有一篇文章介绍了使用 ADO.NET 时应考虑的影响性能的事项：数据访问代码如何影响数据库性能
If you need best performance it is ok. It gives you more control and better performance. By the way here is an article about things you should take into consideration that affects performance while using ADO.NET: How Data Access Code Affects Database Performance
我认为完全没问题。只有您才能确定适合任何给定项目的最佳工具集，并且只要您正确使用它们，遵循最佳实践，就可以使用您认为最好的工具集。
就我个人而言，我更喜欢使用你提到的工具，因为我喜欢更精细的控制。我只使用拖放组件来执行非常简单的任务，嘿，现在这些任务有了动态数据。
I think it's perfectly fine. Only you can determine your best toolset for any given project, and as long as you're using them properly, following best practices, use what you think is best.
Personally, I prefer to use the tools you mentioned, because I like the finer control. I only use the drag-and-drop components for very simple tasks, and hey, there's now Dynamic Data for those tasks.
是的，你是对的，它具有最好的性能，但是在做出决定之前你必须考虑所有的要点，有一些 ORM 工具可以控制你所有的数据访问层，而且它们的性能很好。
Yes you're right, it has the best performance, but you have to consider all the points before take the decision, there are ORM tools that can control all of your data acces layer, and they are just fine in performance.
是的，我认为完全没问题！我个人喜欢拥有完全的控制权，准确定义数据库交互的方式，并让您对性能调整/优化有绝对的控制权。
只是想补充一点，当然 SqlDataAdapters 和 DataTables 也可能有它们的位置，特别是如果想要传递断开连接的数据。
Yes, I think it's perfectly OK! I personally like having the full control, to define exactly how db interation is made and giving you absolute control over performance tuning/optimisation.
Just wanted to add that of course SqlDataAdapters and DataTables may have their place too, especially if wanting to pass disconnected data around.
您可能还想查看企业库。它使用基本的 ADO.Net 对象，同时最大限度地减少在代码中进行这些调用所需的代码。
You may also want to look into Enterprise Library. It uses the basic ADO.Net objects while minimizing the code required to make these calls in your code.