Question

我看过许多引用声明TableAdapters很弱而且很傻，任何真正的开发人员都会使用DataAdapter。我不知道这是不是真的，但我正在探索这个问题，并强调整个'DataAdapter / TableAdapter对类型化DataSet的气味有多糟糕。

让我试着解释......

假设我在xsd文件中有我的Typed DataSet defind，现在我已准备好在代码中创建一个DataAdapter，针对该模式......（顺便说一句，我使用OleDb来访问独立的.dbf文件夹中的文件...没有SQL服务器存储过程在这里调用，只是普通的原始表，准备采取行动。）

到目前为止，从我的研究中，我看到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表架构同步是非常糟糕的。

当然我错过了什么。

真是一场闹剧。类型化的数据集与美丽的intellisense和all一起使用，因为它是从模式生成的，但是当它归结为它时，编写与Typed模式匹配的SQL可能会很痛苦。他们所做的就是把头痛带到一个新的领域。

请告诉我，我在这里错过了一些会让这更好的事情。

Answer 1

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

也许我没有给予足够的重视，但我不知道有任何理由避免使用TableAdapters和DataAdapter。你有一两个链接吗？

Answer 2

我不相信你错过任何东西;保持这种类型的代码永远不会有趣。值得庆幸的是，我们现在拥有LINQ to SQL和Entity Framework，它们可以减少保持模型对象与数据库同步所需的手动代码维护量。

针对Typed DataSet的DataAdapter = SQL Schema噩梦

2 个答案: