Question

在BizTalk帮助程序类中直接调用SQL Server存储过程有哪些潜在的副作用和风险？

我一直在查看一些代码并找到了像......这样的例子。

private static void SaveInvoice(long id, string fileName)
{
    try
    {
        using (SqlConnection sqlConnection = new SqlConnection("... server ..."))
        {
            sqlConnection.Open();
            sqlCommand = new SqlCommand("usp_SaveDocument", sqlConnection);
            sqlCommand.CommandType = CommandType.StoredProcedure;
            sqlCommand.Parameters.AddWithValue("@Id", id);
            sqlCommand.Parameters.AddWithValue("@FileName", fileName);
            sqlCommand.ExecuteNonQuery();
        }
    }
    finally 
    { 
      sqlCommand.Dispose(); 
    }
}

这似乎是一种难闻的气味＆＃34;在BizTalk开发方面。

但是在＆＃34;帮助＆＃34;中进行这种直接数据库调用是否存在任何真正的风险/限制？码？

Answer 1

我的意见：

这很大程度上取决于你想要达到的目标。

BizTalk非常适合可靠消息传递，这正是您在使用适配器时所使用的。当您使用帮助程序类时，您需要知道自己在做什么，因为它是一种不同的技术。通常，您在业务流程中调用辅助类。您需要以不同的方式或更好地思考错误处理，逻辑对业务流程的影响等等......
BizTalk应用程序可以像你想象的那样通用，配置在很大程度上取决于绑定（发送端口/接收位置的集合等等）。从系统移动系统可以像更改发送端口URI一样简单。在执行辅助类时，您需要在某处存储不同的连接字符串。这可以是BTSNTSvc64.exe.config或其他。阅读：通过添加另一个依赖项，可以使您的解决方案更加复杂。

所以，我认为在某些情况下从编排中调用辅助类是完全正常的。

处理您需要存储的内容时可能就是这种情况，这只是消息本身的一个小数据集。例如，确保重复检测/保持自己的跟踪。例如，您需要存储消息/实例中需要关联的内容的任何情况。

通过助手类将整个消息保存到SQL表中 - 无论出于何种原因 - 对我来说似乎并不是很好。这应该由BizTalk适配器完成。

Answer 2

代码方面，确实没有“风险”，它只是.Net代码调用SQL Server。

但是，我认为在BizTalk应用程序中这样做的形式各不相同，因为它，而不是BizTalk方式。那将是一个Schema，Map，SQL Adapter等。

风险在于这样的操作基本上都隐藏在应用程序中，而不是BizTalk Developer期望找到它的位置。

Answer 3

只要你管理你的连接就不会有任何问题。＆＃34;使用＆＃34;甚至对于SqlCommand也建议使用语句，我们已经做了很长时间，到目前为止没有任何问题。

直接调用BizTalk帮助程序类中的存储过程有哪些潜在的副作用？

3 个答案: