针对类型化数据集的数据适配器 = SQL 模式噩梦

Question

我看到很多参考文献都指出 TableAdapter 既弱又愚蠢，任何真正的开发人员都会使用 DataAdapter。 我不知道这是否属实，但我正在探索这个问题，并强调整个“DataAdapter/TableAdapter against a Typed DataSets”的味道有多糟糕。

让我尝试解释一下...

假设我在 xsd 文件中定义了类型化数据集，现在我准备在代码中针对该架构创建一个 DataAdapter...（顺便说一句，我正在使用 OleDb 来访问文件夹中的独立 .dbf 文件...这里没有可调用的 SQL Server 存储过程，只是普通的旧原始表，准备好执行操作。）

从我到目前为止的研究来看，以下是我如何看到 DataAdapter 与类型化数据集。 告诉我我是否错了。 （最后我有一个大抱怨/问题。）

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 可能会很痛苦。 他们所做的只是将令人头疼的问题转移到新的领域。

请告诉我，我在这里缺少一些东西，可以让这变得更好。

Answer 1

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

也许我没有给予足够的重视，但我不知道有什么充分的理由来避免使用 TableAdapter 和 DataAdapter。 你有一个或两个链接吗？

Answer 2

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