我有一个只能通过存储过程与数据库进行交互的功能。我尝试了各种用于调用存储过程的技术。根源是SqlCommand类，但是我想实现几件事：

• 使c＃和sql之间的接口更平滑，以便过程调用看起来更像c＃函数调用
• 有一种简单的方法来确定是否在代码中的任何地方调用了给定的存储过程。
• 方便快捷地创建过程调用。

我探索了各种途径。在一个项目中，我有一个项目，其名称空间结构反映了存储过程的名称结构，这样我就可以从类的名称生成存储过程的名称，并且可以判断给定的存储过程是否在使用中通过在名称空间树中对其进行优化。还有什么其他的经验？

解决方案

我们应该尝试LINQ to SQL。

当存储过程是数据库的接口时，我倾向于将它们包装在反映问题域的类中，以便大多数应用程序代码正在使用这些对象，而不是调用存储过程，甚至不了解存储过程或者数据库连接。应用程序对象通常在它们之间进行播放。

我认为在应用程序中镜像SP是一个错误，因为通常，关系模型与应用程序域对象模型不是1-1.

例如，通常我没有代表链接表或者数据库设计和规范化其他工件的应用程序对象。这些是包含在其他对象中或者由其他对象返回的对象的集合。

阻抗失配的原因很多，但是我认为，让数据库做他们擅长的事情而OO模型做他们擅长的事情的过程是很重要的。

我们是否考虑过使用MS的企业库？它使我们可以轻松地调用存储过程。我通常为每个数据库设置一个仅用于调用这些存储的proc的类。然后，我们可以拥有与此类似的东西(对不起，它是vb.net而不是c＃)：

Public Shared Function GetOrg(ByVal OrgID As Integer) As System.Data.DataSet
    Return db.ExecuteDataSet("dbo.cp_GetOrg", OrgID)
End Function

其中db定义为：

Dim db As Microsoft.Practices.EnterpriseLibrary.Data.Database = DatabaseFactory.CreateDatabase()

然后，我们具有用于调用存储过程的这一功能。然后，我们可以在代码中搜索该功能。

我们想要的最简单的解决方案(并且我并不是说它比其他解决方案好还是坏)是创建数据集并将存储过程从服务器资源管理器拖到数据集设计器表面。这将在适配器中创建可以调用并检查引用的方法。

在构建当前产品时，我非常想实现的工具之一是数据库类(仅我不喜欢该类的DatabaseFactory)，这将简化我的开发并消除一些"陷阱"。在该类中，我希望能够使用函数到过程的映射将存储过程作为真正的Cfunction进行调用，如下所示：

public int Call_MySproc(int paramOne，bool paramTwo，ref int outputParam)

{

...这里的参数处理和sproc调用

}

但是，尝试执行此操作时面临的最大问题是创建实现sproc调用的Cfunction所需的工作。幸运的是，在T-SQL中创建代码生成器很容易做到这一点。我从最初由Paul McKenzie创建的代码开始，然后以各种方式对其进行了修改，以根据需要生成Ccode。

我们可以选择Google Paul McKenzie并寻找其原始代码生成器，或者，如果我们想在mark -atBSDIWeb.com上给我写信，我将把我的SQL类库以及相关的sproc代码生成器的源捆绑在一起，将其放置在我们的网站上。如果收到一两个请求，我将其发布，然后返回并编辑此响应以将其他请求也指向源。

尽管它们不是很时髦，但我们将Typed DataSets用作所有存储过程的前端。

Microsoft的新Entity Framework可以满足要求。 EF通常用于创建数据库对象的代理类，但是很多人没有意识到的一件事是，它还为存储过程(当然是自动生成)创建了代理方法。这使我们可以像常规方法调用一样使用SP。

一探究竟！