1

我目前正在执行以下操作以在 vs2008 中使用类型化数据集：

右键单击“app_code”添加新数据集，将其命名为 tableDS。

打开tableDS，右键，添加“表格适配器”

在向导中，选择一个预定义的连接字符串，“使用 SQL 语句”

select * from tablename and next + next 完成。（我为数据库中的每个表生成一个表适配器）

在我的代码中，当我只需要一个数据时，我会执行以下操作来获取一行数据：

cpcDS.tbl_cpcRow tr = (cpcDS.tbl_cpcRow)(new cpcDSTableAdapters.tbl_cpcTableAdapter()).GetData().Select("cpcID = " + cpcID)[0];

我相信这将从数据库中获取整个表并在 dotnet 中进行过滤（即不是最佳的），有什么办法可以让 tableadapter 来过滤数据库上的结果集（即我想要的是发送选择* 从 tbl_cpc 其中 cpcID = 1 到数据库）

作为旁注，我认为这是从 vs2008 中的数据库获取数据的一种相当不错的设计模式。它的编码、阅读和维护相当容易。但我想知道还有其他更好的设计模式吗？我使用数据集进行读取/更新/插入和删除。

4

3 回答 3

1

有点转变，但您询问不同的模式 - LINQ 怎么样？由于您使用的是 VS2008，因此（尽管不能保证）您也可以使用 .NET 3.5。

LINQ-to-SQL 数据上下文提供了对数据（过滤等）的更多托管访问。这是一个选项吗？不过，我不确定目前是否会使用“实体框架”（请参见此处）。

根据请求编辑：

要从数据上下文中获取一行，您只需指定“谓词” - 在这种情况下，主键匹配：

int id = ... // the primary key we want to look for
using(var ctx = new MydataContext()) {
   SomeType record = ctx.SomeTable.Single(x => x.SomeColumn == id);
   //... etc

   // ctx.SubmitChanges(); // to commit any updates
}

上面使用 Single 是经过深思熟虑的——这种特殊用法 [Single(predicate)] 允许数据上下文充分利用本地内存中的数据——即，如果谓词只是在主键列上，它可能不必如果数据上下文已经看到该记录，请完全触摸数据库。

但是，LINQ 非常灵活。您还可以使用“查询语法” - 例如，稍微不同的（列表）查询：

    var myOrders = from row in ctx.Orders
                   where row.CustomerID = id && row.IsActive
                   orderby row.OrderDate
                   select row;

ETC

于 2008-11-17T11:03:08.970 回答
1

使用类型化数据集有两个潜在问题，

一是可测试性。在使用类型化数据集时，设置要在单元测试中使用的对象是一项相当艰巨的工作。

另一个是可维护性。使用类型化的数据集通常是更深层次问题的症状，我猜你所有的业务规则都存在于数据集之外，其中相当一部分将数据集作为输入并基于它们输出一些聚合值。这会导致业务逻辑到处泄漏，虽然在前 6 个月里一切都是虚无缥缈的，但一段时间后它就会开始对你不利。数据集的这种使用基本上是非面向对象的

话虽如此，使用数据集建立一个合理的架构是完全可能的，但这并不是自然而然的。ORM 最初设置起来会比较困难，但它很适合编写可维护和可测试的代码，因此您不必回顾 6 个月后所造成的混乱。

于 2008-11-17T11:17:31.110 回答
0

您可以将带有 where 子句的查询添加到您感兴趣的表的 tableadapter。

LINQ 很好，但它实际上只是 OP 已经在做的事情的快捷语法。

除非您的数据模型非常复杂，否则类型化数据集非常有意义。那么编写自己的 ORM 将是最好的选择。我有点困惑，为什么 Andreas 认为类型化的数据集很难维护。关于它们的唯一烦人的事情是，每当更改选择命令时，插入、更新和删除命令都会被删除。

此外，与您自己的 ORM 相比，创建类型化数据集的速度优势让您可以专注于应用程序本身，而不是数据访问代码。

于 2009-01-09T19:44:53.253 回答