将 mvc-mini-profiler 与 ADO.NET SqlConnection 结合使用
我正在尝试将(很棒的)mvc-mini-profiler 与一些预先存在的 SqlConnection 存储过程代码结合使用(我们不使用 EF 或 L2S,仅使用 ADO.NET 到 SQL Server 2008)。我正在寻找一些有关如何将继承的 ProfiledDb
类型集成到此类代码中的指导。
var con = new SqlConnection("connectionstring");
var cmd = new SqlCommand();
cmd.CommandType = CommandType.StoredProcedure;
cmd.Connection = con;
cmd.CommandText = "SP_STORED_PROCEDURE_NAME";
cmd.Paramters.Add("recordsetid",SqlDbType.UniqueIdentifier).Value = recordsetid;
var dSet = new DataSet();
var da = new SqlDataAdapter(cmd);
da.fill(dSet);
<parse DataSet>
对于我们传统的 ADO.NET 用户来说,这里的任何帮助都会很棒,因为从表面上看,SQL 分析器应该适用于这种情况
I'm attempting to utilize the (awesome) mvc-mini-profiler with some pre-existing SqlConnection stored procedure code (we don't use EF or L2S, just ADO.NET to SQL Server 2008). I'm looking for some guidance on how to integrate the inherited ProfiledDb
types into this kind of code.
var con = new SqlConnection("connectionstring");
var cmd = new SqlCommand();
cmd.CommandType = CommandType.StoredProcedure;
cmd.Connection = con;
cmd.CommandText = "SP_STORED_PROCEDURE_NAME";
cmd.Paramters.Add("recordsetid",SqlDbType.UniqueIdentifier).Value = recordsetid;
var dSet = new DataSet();
var da = new SqlDataAdapter(cmd);
da.fill(dSet);
<parse DataSet>
Any help here for us legacy ADO.NET users would be great because on the surface it appears that the SQL profiler should be applicable to this situation
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您需要做的就是包装您的连接并使用 DbConnection CreateCommand 工厂。
类似地,要传递参数,您需要使用基本接口方法,并避免像
SqlParameter
这样的东西,因为它没有被包装。所以:
我还没有测试过 DataSets 和 DataAdapters,老实说,这些天我使用 Dapper 来做这类事情,因为它不那么冗长。如果出现这种情况,请务必报告 Google 代码。
You will need to do is wrap up your connection and use the DbConnection
CreateCommand
factory.Similarly to pass params you will need to use the base interface methods, and avoid stuff like
SqlParameter
cause it is not wrapped.So:
I have not tested DataSets and DataAdapters, honestly I use Dapper for this kind of stuff these days as it is much less verbose. If it plays up, be sure to report on Google code.
我也遇到过类似的情况,我们所有的 SQL 都在存储过程中,而我们只需使用 ADO.NET 代码来调用它们。我还有一个我很满意的数据访问层,因此不喜欢仅仅为了适应 MiniProfiler 而必须重写它的大块的想法。
因此,我做出的妥协是在过程调用周围使用标准
MiniProfiler.Step()
调用。在我的情况下,对 ExecuteReader() 等的所有调用都是基类的一部分,因此我知道所有 SqlCommands 都会在几个基方法中执行,因此很容易将我现有的代码更改为看起来与此类似:我确信这不如 Sam 的答案那么好,因为我确信结果选项卡中会缺少一些详细信息,但它足以让我现在只需很少的更改即可分析数据库调用我的数据访问代码结构。
I have a similar situation where all our SQL is in stored procedures and we simply have ADO.NET code that calls into them. I also have a data access layer that I am happy with so do not like the idea of having to rewrite chunks of it simply to accommodate MiniProfiler.
So the compromise I settled on was to use the standard
MiniProfiler.Step()
calls around the procedure calls. It helps in my case that all calls toExecuteReader()
et al are part of a base class so I know all SqlCommands get executed within a few base methods, so it was easy to change my existing code to look similar to this:I'm sure that this isn't as good as Sam's answer as I'm sure some details will be missing in the results tab, but it works well enough for me to analyse database calls now with very little changes to my data access code structure.