8

最近我发现自己正在编写数据访问层选择方法，其中代码都采用这种一般形式：

public static DataTable GetSomeData( ... arguments)
{
    string sql = " ... sql string here:  often it's just a stored procedure name ... ";

    DataTable result = new DataTable();

    // GetOpenConnection() is a private method in the class: 
    // it manages the connection string and returns an open and ready connection
    using (SqlConnection cn = GetOpenConnection())
    using (SqlCommand cmd = new SqlCommand(sql, cn))
    {
        // could be any number of parameters, each with a different type
        cmd.Parameters.Add("@Param1", SqlDbType.VarChar, 50).Value = param1; //argument passed to function

        using (SqlDataReader rdr = cmd.ExecuteReader())
        {
            result.Load(rdr);
        }
    }

    return result;
}

或者像这样：

public static DataRow GetSomeSingleRecord( ... arguments)
{
    string sql = " ... sql string here:  often it's just a stored procedure name ... ";

    DataTable dt = new DataTable();

    // GetOpenConnection() is a private method in the class: 
    // it manages the connection string and returns an open and ready connection
    using (SqlConnection cn = GetOpenConnection())
    using (SqlCommand cmd = new SqlCommand(sql, cn))
    {
        // could be any number of parameters, each with a different type
        cmd.Parameters.Add("@Param1", SqlDbType.VarChar, 50).Value = param1; //argument passed to function

        using (SqlDataReader rdr = cmd.ExecuteReader(CommandBehavior.SingleRow))
        {
            dt.Load(rdr);
        }
    }

    if (dt.Rows.Count > 0)
         return dt.Rows[0];
    return null;
}

这些方法将由业务层代码调用，然后将基本 DataTable 或 DataRecord 转换为表示层可以使用的强类型业务对象。

由于我反复使用类似的代码，我想确保这个代码是最好的。那么如何改进呢？而且，是否值得尝试将通用代码从这里移到它自己的方法中。如果是这样，该方法会是什么样子（特别是关于传入 SqlParameter 集合）？

4

7 回答 7

3

必须添加我自己的：
在 Using 语句中从 DataLayer 返回 DataReader

新模式使我一次只能在内存中拥有一条记录，但仍将连接包含在一个不错的“使用”语句中：

public IEnumerable<T> GetSomeData(string filter, Func<IDataRecord, T> factory)
{
    string sql = "SELECT * FROM [SomeTable] WHERE SomeColumn= @Filter";

    using (SqlConnection cn = new SqlConnection(GetConnectionString()))
    using (SqlCommand cmd = new SqlCommand(sql, cn))
    {
        cmd.Parameters.Add("@Filter", SqlDbType.NVarChar, 255).Value = filter;
        cn.Open();

        using (IDataReader rdr = cmd.ExecuteReader())
        {
            while (rdr.Read())
            {
                yield return factory(rdr);
            }
            rdr.Close();
        }
    }
}
于 2009-05-12T18:15:51.957 回答
2

就客户端代码而言，我喜欢的一种模式如下所示：

        DataTable data = null;
        using (StoredProcedure proc = new StoredProcedure("MyProcName","[Connection]"))
        {
            proc.AddParameter("@LoginName", loginName);
            data = proc.ExecuteDataTable();
        }

我通常将连接设为可选，并且我会以某种方式进行编码，以便从 ConnectionStrings 配置部分中提取它或将其视为实际的连接字符串。这让我可以在一个场景中重用 dal，并且在某种程度上是 COM+ 时代的习惯，当时我使用对象构造属性存储连接字符串。

我喜欢这个，因为它易于阅读并且对我隐藏了所有 ADO 代码。

于 2009-01-12T16:52:41.993 回答
2

类似于我在这里发布的内容

public IEnumerable<S> Get<S>(string query, Action<IDbCommand> parameterizer, 
                             Func<IDataRecord, S> selector)
{
    using (var conn = new T()) //your connection object
    {
        using (var cmd = conn.CreateCommand())
        {
            if (parameterizer != null)
                parameterizer(cmd);
            cmd.CommandText = query;
            cmd.Connection.ConnectionString = _connectionString;
            cmd.Connection.Open();
            using (var r = cmd.ExecuteReader())
                while (r.Read())
                    yield return selector(r);
        }
    }
}

我有这些简单的扩展方法来帮助调用：

public static void Parameterize(this IDbCommand command, string name, object value)
{
    var parameter = command.CreateParameter();
    parameter.ParameterName = name;
    parameter.Value = value;
    command.Parameters.Add(parameter);
}

public static T To<T>(this IDataRecord dr, int index, T defaultValue = default(T),
                      Func<object, T> converter = null)
{
    return dr[index].To<T>(defaultValue, converter);
}

static T To<T>(this object obj, T defaultValue, Func<object, T> converter)
{
    if (obj.IsNull())
        return defaultValue;

    return converter == null ? (T)obj : converter(obj);
}

public static bool IsNull<T>(this T obj) where T : class
{
    return (object)obj == null || obj == DBNull.Value;
}

所以现在我可以打电话了：

var query = Get(sql, cmd =>
{
    cmd.Parameterize("saved", 1);
    cmd.Parameterize("name", "abel");
}, r => new User(r.To<int>(0), r.To<string>(1), r.To<DateTime?>(2), r.To<bool>(3)));
foreach (var user in query)
{

}

这是完全通用的，适合任何符合 ado.net 接口的模型。连接对象和阅读器仅在集合被枚举一次后才被释放。

于 2013-02-14T08:12:52.317 回答
1

唯一不同的是我从自己的内部数据库帮助器方法切换到实际的数据访问应用程序块http://msdn.microsoft.com/en-us/library/cc309504.aspx

让其他了解企业库的开发人员在代码上更加标准化/统一。

于 2009-01-12T16:52:19.013 回答
1

有很多方法可以实现 DBAL，在我看来，您走在正确的道路上。在您的实施中需要考虑的事项：

  • 您正在使用类似工厂的方法来创建 SqlConnection，这是一个小问题，但您可以对 SqlCommand 执行相同的操作。
  • 参数长度是可选的，因此您实际上可以将其排除在 Parameter.Add 调用之外。
  • 创建添加参数的方法，代码示例如下。

使用添加参数DbUtil.AddParameter(cmd, "@Id", SqlDbType.UniqueIdentifier, Id);

internal class DbUtil {

internal static SqlParameter CreateSqlParameter(
    string parameterName,
    SqlDbType dbType,
    ParameterDirection direction,
    object value
) {
    SqlParameter parameter = new SqlParameter(parameterName, dbType);

    if (value == null) {
        value = DBNull.Value;
    }

    parameter.Value = value;

    parameter.Direction = direction;
    return parameter;
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType
) {
    return AddParameter(sqlCommand, parameterName, dbType, null);
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType,
    object value
) {
    return AddParameter(sqlCommand, parameterName, dbType, ParameterDirection.Input, value);
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType,
    ParameterDirection direction,
    object value
) {
    SqlParameter parameter = CreateSqlParameter(parameterName, dbType, direction, value);
    sqlCommand.Parameters.Add(parameter);
    return parameter;
    }
}
于 2009-01-12T17:13:55.210 回答
1

首先，我认为您已经考虑过使用 ORM 与自己滚动。我不会进入这个。

我对滚动自己的数据访问代码的想法：

  • 随着时间的推移，我发现不使用单独的 DAL/BL 对象更容易，而是将它们合并为一个对象（在得出这个结论后的一段时间后，我发现这是一个众所周知的模式 - 即 ActiveRecord）。拥有单独的 DAL 程序集可能看起来不错且解耦，但维护成本的开销会增加。每次添加新功能时，您都必须创建更多代码/修改更多类。根据我的经验，维护应用程序的团队通常比构建它的原始开发团队少得多，而且他们会讨厌所需的额外工作。
  • 对于大型团队来说，将 DAL 分开可能是有意义的（让一个小组在其他人的时候处理它。但这对代码膨胀来说是一个很好的激励。
  • 归结为您的具体示例：您如何使用生成的 DataTable？迭代行、创建类型对象并从行中获取数据？如果答案是肯定的，请考虑为在 DAL 和 BL 之间移动数据而创建的额外 DataTable。为什么不直接从 DataReader 中获取呢？
  • 另外关于示例：如果您返回一个无类型的 DataTable，那么我想您必须在调用代码中使用列名（SP 调用返回的结果集）。这意味着如果我必须更改数据库中的某些内容，它可能会影响两个层。

我的建议（我尝试了这两种方法 - 该建议是我提出的最新工作方法 - 它随着时间的推移而演变）。

  • 为您的类型化业务对象创建一个基类。
  • 在基类中保持对象状态（新的、修改的等）
  • 把主要的数据访问方法放在这个类中，作为静态方法。稍加努力（提示：泛型方法 + Activator.CreateInstance），您可以为读取器中返回的每一行创建一个业务对象。
  • 在业务对象中创建一个抽象方法来解析行数据（直接来自 DataReader！）并填充对象。
  • 在派生业务对象中创建静态方法，这些方法准备存储的过程参数（取决于各种过滤条件）并从基类调用通用数据访问方法。

目的是最终得到以下用途：

List<MyObject> objects = MyObject.FindMyObject(string someParam);

对我的好处是我只需要更改一个文件即可应对数据库列名、类型等的更改（通常是小的更改）。使用一些经过深思熟虑的区域，您可以组织代码，以便它们在同一个对象中成为单独的“层”:)。另一个好处是基类确实可以从一个项目重用到另一个项目。而且代码膨胀很小（好吧，与好处相比。您还可以填充数据集并将它们绑定到 UI 控件：D

限制 - 每个域对象（通常每个主数据库表）都有一个类。而且您不能在现有事务中加载对象（尽管您可以考虑传递事务，如果有的话）。

如果您对更多细节感兴趣，请告诉我 - 我可以稍微扩展一下答案。

于 2009-01-14T22:45:19.003 回答
-2

最简单的解决方案：

var dt=new DataTable();
dt.Load(myDataReader);
list<DataRow> dr=dt.AsEnumerable().ToList();
于 2017-09-10T06:21:15.830 回答