1

我看到很多参考资料说 TableAdapter 很弱而且很愚蠢，并且任何真正的开发人员都会使用 DataAdapter。我不知道这是否属实，但我正在探索这个问题，并强调整个“DataAdapter/TableAdapter 针对 Typed DataSets”的气味有多糟糕。

让我试着解释一下……

假设我在 xsd 文件中有我的 Typed DataSet 定义，现在我准备在代码中创建一个 DataAdapter，针对该模式......（顺便说一下，我正在使用 OleDb 访问独立的 .dbf 文件文件夹...这里没有要调用的 SQL Server 存储过程，只是普通的旧原始表，准备好执行操作。）

从我目前的研究来看，这是我如何看待 DataAdapter 与 Typed DataSet 一起使用的。告诉我我是否错了。（最后我有我的大抱怨/问题。）

public DataTable GetJobsByCustomer(string CustNo)
{
    OleDbConnection conn1 = new OleDbConnection(dbConnectionString);
    conn1.Open();

    LMVFP ds1 = new LMVFP(); //My Typed DataSet

    string sqlstring = @"SELECT act_compda, contact, cust_num, est_cost, invoiced, job_hours,
                        job_invnum, job_num, job_remark, job_start, mach_cost, mat_cost, mat_mkup,
                        p_o_num, priority, quote_no, quoted_by, ship_date, ship_info, shop_notes, status, total_cost
                        FROM job_info
                        WHERE (cust_num = ?) AND (status = 'A')
                        ORDER BY priority";

    OleDbDataAdapter JobsAdapter = new OleDbDataAdapter(sqlstring,conn1);
    JobsAdapter.SelectCommand.Parameters.Add("?", OleDbType.VarChar,6).Value=CustNo;

    JobsAdapter.Fill(ds1, "Jobs"); // A table schema in the Typed DataSet

    return ds1.Jobs;

}

事情是这样的吗？它确实有效，所以这很好。确实，强类型行为很棒。

现在，我的抱怨......你的意思是告诉我，我已经在我的 DAL 方法 (GetJobsByCustomer) 中维护了相同的 exaxt SQL 语法，以匹配 xsd 中表的架构？在我的手工编码的 SQL 和 xsd 模式之间进行如此多的维护和分离真是太疯狂了。根本没有错误，因为您正在编写文本字符串！您可以在运行时确定它是否有效。

当您在代码中键入所有 SQL 时，必须来回查看以使您的编码 SQL 与 xsd 表模式保持同步，这很糟糕。

当然，我错过了一些东西。

真是一场闹剧。类型化的数据集可以与漂亮的智能感知一起使用，因为它是从模式生成的，但是归根结底，编写与类型化模式匹配的 SQL 只是一件痛苦的事。他们所做的只是将头痛转移到一个新的领域。

请告诉我，我在这里遗漏了一些可以使情况变得更好的东西。

4

2 回答 2

1

我赞同 Adam 对 LINQ to SQL 和 EF 的赞赏，但我认为这对您来说（目前）还不是一个选择，因为缺乏对第三方 DBMS 的支持。另一方面，第三方 ORM（例如 NHibernate）可能是一种选择。

也许我没有给予足够的关注，但我不知道有什么好的理由避免使用 TableAdapters 和 DataAdapters。你有一两个链接吗？

于 2009-04-02T19:53:21.307 回答
0

我不相信你缺少任何东西；维护这种类型的代码从来都不是一件有趣的事情。值得庆幸的是，我们现在拥有 LINQ to SQL 和实体框架，它们都可以减少使模型对象与数据库保持同步所需的手动代码维护量。

于 2009-04-02T19:27:42.820 回答