我正在尝试创建一个存储过程/ADO.NET 映射机制，其中带有参数的存储过程变为
object MyStoredProcedure.Execute(out returnValue, param1, param2, ...)
当尝试生成实际的数据检索方法时，问题就来了。我可以很容易地从 Information Schema View 中获取我需要的大部分模式信息，但我无法可靠地找到哪种类型的返回(输出参数与 SELECT/SqlDataReader 与两者)应该来自该过程以及是否调用 ExecuteNonQuery或执行阅读器。
最坏的情况，我可能可以解析过程的文本，但那里可能会出现各种奇怪的事情。
代码生成的原因是应用程序数据库包含数百个存储过程。而且我们继承了这个项目，所以没有办法绕过我们没有创建的许多过程。
对于 ADO.NET 生成，我实际上有两个主要目标:
1) 从应用程序中删除所有字符串文字(SqlCommand 创建中存储的过程名称、SqlParameter 创建中的参数名称等)。这样，当过程或数据库模式发生变化时，我们可以重新生成 ADO.NET 包装器，并且这些变化导致的任何错误都将在编译时被捕获。
2) 不再需要挖掘过程来确定参数、返回类型等。所以基本上，数据库本身变成了一个 API，所有内部存储过程的细节都被抽象掉了。
最佳答案
是的；这并不容易。对于简单 情况，您可以尝试运行 sp(awooga!)为所有参数传递空值，并使用 SET FMTONLY ON - 有点冒险(扩展存储过程仍然执行，例如)并且不健壮，因为 TSQL 可以在输入上分支。但是一个选项。
“out”ets 应该可以通过元数据获得； “旧”方式是 syscolumns(可能有一个信息模式替代方案可以以正确的方式进行)。
作为更新；如果您希望数据库将自身描述为 API，则可以考虑选择 UDF；优点:
- 返回值的元数据是严格的且易于查询
- 它在调用者处是可组合的
或者；只需使用 ORM。 LINQ-to-SQL 将愉快地使用这种类型的设置(包括可组合性)； Entity Framework 肯定会为您完成存储过程的所有艰苦工作。或任何其他人； NHibernate , LLBLGen Pro等。他们都解决了这个确切的问题。这不是微不足道的；为什么要重新发明它？
关于c# - 确定是否从模式生成 ExecuteNonQuery 或 ExecuteReader，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1469662/