c# - 如何从 SQL 数据库填充 C# 中的通用对象列表

Question

我正在学习 ASP.NET c# 并尝试将最佳实践合并到我的应用程序中。我读到的所有内容都说基于关注点分离将我的应用程序分层为 DAL、BLL、UI 等。我没有传递数据表，而是考虑使用自定义对象，这样我就可以松散地耦合到我的数据层，并且可以利用 VS 中的智能感知。我假设这些对象将被视为 DTO？

首先，这些对象位于我的图层中的什么位置？ BLL、DAL、其他？

其次，当从 SQL 填充时，我应该循环通过数据读取器来填充列表，还是先填充数据表，然后循环通过表来填充列表？我知道您应该尽快关闭数据库连接，但填充数据表然后循环遍历列表似乎需要更多开销。

第三，这些天我看到的所有东西都说使用 Linq2SQL。我打算学习 Linq2SQL，但此时我正在使用没有外键设置的遗留数据库，而且我没有能力在 atm 上修复它。此外，在我开始使用像 nHibernate 这样的 ORM 解决方案之前，我想了解更多关于 c# 的知识。同时，我不想为每个查询键入所有连接和 SQL 管道。现在可以使用企业 DAAB 吗？

Answer 1

你一个问题有很多问题。

Linq2SQL 只是一种 ORM，如果你要走那条路，我会看看 Entity Framework (微软的 orm)。

让我们谈谈分层应用程序，以帮助您了解如何填充对象。 您典型的数据库应用程序由 3 层组成(有人说是 4 层，将数据库本身称为一层，这并不重要)。你有以下内容:

• 用户界面
• BLL
• DAL

所以您的通信是 UI 与 BLL 对话，BLL 与 DAL 对话。 DAL 将一些数据返回给 BLL，BLL 又将其返回给 UI。我不知道谁告诉你数据集/表不好...确保阅读器速度更快，但这并不意味着使用数据表不好。

让我举个例子。不要再将 DAL 视为一个简单的类。开始将 DAL 层视为不同类的整个文件夹。其中一个类是静态数据库类。它是静态的，因为您正在处理一个数据库(在大多数情况下)，因此无需实例化该类。所以它可能看起来像这样:

public static class DB {
private static readonly string connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;
private static readonly DbProviderFactory factory = DbProviderFactories.GetFactory(dataProvider);

public static int Update(string sql)
        {
            using (DbConnection connection = factory.CreateConnection())
            {
                connection.ConnectionString = connectionString;

                using (DbCommand command = factory.CreateCommand())
                {
                    command.Connection = connection;
                    command.CommandText = sql;

                    connection.Open();
                    return command.ExecuteNonQuery();
                }
            }
        }

public static DataTable GetDataTable(string sql)
        {
            using (DbConnection connection = factory.CreateConnection())
            {
                connection.ConnectionString = connectionString;

                using (DbCommand command = factory.CreateCommand())
                {
                    command.Connection = connection;
                    command.CommandType = CommandType.Text;
                    command.CommandText = sql;

                    using (DbDataAdapter adapter = factory.CreateDataAdapter())
                    {
                        adapter.SelectCommand = command;

                        DataTable dt = new DataTable();
                        adapter.Fill(dt);

                        return dt;
                    }
                }
            }
}

其中一些内容取自 dofactory 网站。学习如何使用设计模式的重要资源。无论如何，这只是一个 .class 文件。现在您需要另一个 CustomerDAO(客户数据访问对象)。

好的，那么您如何使用您创建的 DB 类(好吧，我会使用存储过程的组合，但为了使这篇文章变得简单，让我们暂时避免使用存储过程)。如果我需要获取客户，我可以这样定义:

public IList<Customer> GetCustomers()
{
    StringBuilder sql = new StringBuilder();
    sql.Append(" SELECT CustomerId, CompanyName, City, Country ");
    sql.Append("   FROM Customer ");

    DataTable dt = Db.GetDataTable(sql.ToString());

    return MakeCustomers(dt);
}

请记住，这是在一个完全不同的 .class 文件中。好的，那么如何让客户看起来:

private IList<Customer> MakeCustomers(DataTable dt)
        {
            IList<Customer> list = new List<Customer>();
            foreach (DataRow row in dt.Rows)
                list.Add(MakeCustomer(row));

            return list;
        }

所以我在这里做的是我有一个充满客户的数据表。我需要遍历数据表的每一行并让客户:

private Customer MakeCustomer(DataRow row)
        {
            int customerId = int.Parse(row["CustomerId"].ToString());
            string company = row["CompanyName"].ToString();
            string city = row["City"].ToString();
            string country = row["Country"].ToString();

            return new Customer(customerId, company, city, country);
        }

所以这个客户是新客户并存储在客户列表中。

这只是数据访问层功能的一个小例子。数据库类仅存储连接字符串和函数以获取数据集或获取数据表，甚至在您的情况下获取数据读取器(您也可以这样做)。 CustomerDAO 类只是一个处理客户对象的类，可以实现 ICustomer 接口(interface)。

那么 Customer 类本身在哪里呢？它可以作为业务层在另一个文件夹中，因为它只是一个业务对象。在这里，您可以在客户类中设置验证和必填字段。

您的 UI 根本没有任何与数据读取器、数据集或 SQL 相关的内容。您的业​​务层也与它无关(它定义了业务对象背后的一些规则)。您的 dal 可以非常灵活(可以使用 SQL、Oracle 等)，或者如果您打算这样做，则可以限制为说 SQL Server。不要矫枉过正你的应用程序。如果您是一名 MS 专家并且确定只使用 SQL Server，请不要尝试推出适用于任何供应商的终极 DAL，从而让您的工作变得困难。可以使用SQLCommand、SQLConnection等。