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();
}
}
就 BizTalk 开发而言，这似乎是一种"难闻的气味"。
但是在"帮助程序"代码中进行这种直接数据库调用是否有任何真正的风险/限制？
代码方面，实际上没有"风险"，它只是调用SQL Server的.Net代码。
但是，我认为在 BizTalk 应用程序中这样做的形式很糟糕，因为它不是 BizTalk 方式。 那将是一个架构，映射，SQL适配器等。
风险在于，此类操作实质上隐藏在应用程序中，而不是 BizTalk 开发人员希望找到它的位置。
我的意见：
这在很大程度上取决于您要实现的目标。
-
BizTalk 在可靠消息传递方面非常好，这正是您在使用适配器时使用的内容。使用帮助程序类时，需要知道自己在做什么，因为它是一种不同的技术。例如，您经常在业务流程中调用帮助程序类。您需要以不同的方式思考，或者更好地考虑错误处理，逻辑对业务流程的影响等......
-
BizTalk 应用程序可以像您想象的那样通用，并且配置在很大程度上取决于绑定(发送端口/接收位置的集合等...从一个系统移动到另一个系统可以像更改发送端口 URI 一样简单。执行帮助程序类时，需要将不同的连接字符串存储在某处。这可以是BTSNTSvc64.exe.config或其他东西。阅读：通过添加另一个依赖项使您的解决方案更加复杂的东西。
因此，我认为在某些情况下，从业务流程调用帮助程序类是完全可以的。
在处理需要存储的内容时，可能就是这种情况，该存储只是消息本身的一个小数据集。例如，确保重复检测/保持自己的跟踪。例如，您需要从消息/实例中存储某些内容的任何情况，例如，您需要与之关联。
通过帮助程序类将整个消息保存到SQL表中 - 无论出于何种原因 - 对我来说似乎都不是很好。这应该由 BizTalk 适配器完成。
只要您管理好连接就不会有任何问题。即使对于 SqlCommand，也建议使用"语句，我们已经这样做了很长时间，到目前为止没有任何问题。