如何在C#.NET中保存存储过程DRY?

时间:2008-11-08 05:45:56

标签: .net stored-procedures dry

我们将每个查询的存储过程用于数据库。这看起来令人难以置信 - DRY

  1. 设计表格
  2. 为该表设计CRUD操作SP
  3. 设计代码(最好是一个类)来填充参数并执行CRUD SP
  4. 如果我们添加单个列或更改数据类型,我们必须在.NET中的类中编辑表,一些SP和一些函数。

    减少此重复有哪些提示?

    更新:

    结合Vinko的想法,我找到了this。这里有一些代码(在C#中),我想出了那些需要它的代码:

    SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["MySQLConnString"].ConnectionString);
    SqlCommand comm = new SqlCommand("NameOfStoredProcedure", conn);
    comm.CommandType = CommandType.StoredProcedure;
    
    conn.Open();
    SqlCommandBuilder.DeriveParameters(comm);
    conn.Close();
    
    foreach (SqlParameter param in comm.Parameters)
    { /* do stuff */ }
    

8 个答案:

答案 0 :(得分:2)

我建议使用代码生成工具(如NetTiers)生成CRUD图层。

答案 1 :(得分:2)

避免修改至少SP的一个提示是将它们写为使用'introspection',即从内部表或information_schema视图中推断出列名和数据类型。

要编写的代码更复杂,但每次表更改时都要避免修改它,并且可以在其余的SP中重用它。

创建一个将为您描述表的SP,例如使用您将从其余SP调用的临时表(colname varchar,type varchar)。

顺便说一句,如果您的查询很复杂,这可能会变得非常复杂甚至不可行,但另一方面,如果它们不是,那么它可以为您节省很多麻烦。

答案 2 :(得分:1)

OOP设计原则适用于程序代码,而不是声明性代码。特别是重用SP是非常有问题的。

基于CRUD生成器的UI设计名称很好。另一种明确将用户转变为数据录入员的方法。如果您使用这些,请确保在它们生成的内容和用户必须处理的内容之间有一个很好的抽象层。

  

如果我们添加单个列或更改数据类型,我们必须在.NET中的类中编辑表,一些SP和一些函数。

听起来您的数据库设计正在规定您的OOP要求。从另一个方向开始。

答案 3 :(得分:1)

一旦SQL超出单个表,所有这些元查询方法都会在其轨道中消失。或者想要一个计算列。或者......

答案 4 :(得分:1)

就个人而言,我不是将查询代码放入存储过程的忠实粉丝。除了高度复杂的东西外,它看起来似乎是多余的过度杀伤。

以下是我处理数据库和crud对象设计的方法:

  1. 我创建数据模型
  2. 我为每个表创建一个视图
  3. 我创建了插入,更新和&删除每个表的过程。
  4. 我所有的C#代码都指向了视图和过程。
  5. 这允许我:

    1. 拥有高度灵活的查询目标(视图)
    2. 以任何方式查询视图,无需冗余。
    3. 通过数据库安全防止直接访问表
    4. 摘要我需要重构基础数据模型的事件中的数据模型,而不会破坏我的代码(我知道,这可能会产生性能成本)
    5. 有一个代表目标表的视图可能会处理许多查询,即使它没有,最糟糕的情况是你需要专门为查询创建一个视图,这相当于创建一个proc它,所以没有不好的一面。

      我听到人们建议使用存储过程来防止SQL注入攻击,但是如果在查询视图时使用参数化查询,这无论如何都不会成为问题。 ......我们总是以任何方式使用参数化查询......对吗? ; - )

答案 5 :(得分:1)

您使用的'DeriveParameters'方法确实有效,但每个请求涉及2次数据库跳转。这种方法会受到性能影响。 Microsoft的数据访问应用程序块SqlHelper类将通过执行完全相同的“内省”来缓解此问题,但可选地缓存参数以供重用。这将允许您创建单行SP调用,而无需重复的“goo”设置参数等。

http://msdn.microsoft.com/en-us/library/cc309504.aspx

答案 6 :(得分:0)

我认为这不属于DRY指南。这只是关于持久性,如果您手动执行#3,那么您应该考虑采用一种使这更容易的工具集。 LINQ to SQL是我个人的最爱,但有很多。

您的#2也可轻松实现自动化。减少1)设计数据模型(概念)2)在持久层实现它(创建表,或添加列)3)在应用程序级别使用它。

答案 7 :(得分:0)

有些表不具有CRUD,不应该从您的应用程序访问,并且是数据库实现模型的工件。特别是,您的应用程序不应访问多对多链接表,它们应由数据库通过存储过程进行管理。