ASP.NET DataSet与Business Objects / ORM

Question

我在考虑ASP.NET应用程序的数据访问。来自一家使用大量Windows应用程序和客户数据集的公司，对于处理数据的DataSet方法存在着自然的优势。

我更热衷于业务对象方法，我不喜欢在会话中缓存DataSet然后应用更新的想法。

有没有人有任何经验/帮助来传递这两种方法的利弊？

Answer 1

您可以考虑在应用中设计数据层。在ASP.NET应用程序中，这将帮助您标准化并极大地简化数据访问。 将需要学习如何创建和使用ObjectDataSources，但这非常简单。

数据访问层（使用单独的项目/ DLL构建）的另一个优点是它使单元测试更加简单。我还鼓励你构建一个业务层来完成大部分数据处理（例如，业务层负责将ObjectDataSources从DAL拉到UI代码）。这不仅可以封装您的业务逻辑，还可以提高代码的可测试性。

你不想要在会话中缓存DataSet（或者DAL对象）！您将构建一个Web应用程序，以便记录修改通过唯一ID（或其他主键规范）工作，并在更改时直接将更改提供给DAL。如果您要缓存所有内容，那么显着会降低应用的可扩展性。

更新：此线程上的其他人正在宣传使用ORM的想法。由于我之前概述here和here的原因，我会谨慎地采用完整的ORM。但是，做同意，避免使用DataSet是明智之举。在我自己的工作中，我广泛使用DataReaders来填充我的ObjectDataSources（由于我的DAL的设计，这很简单）并且发现它非常有效。

Answer 2

与其他ADO.NET对象（如DataReader）相比，DataSet的效率极低。我建议你根据你的意思走向BO / ORM路线。

Answer 3

如果您要遵循微软的方向，那么趋势肯定是针对LINQ（ORM）与DataSet。当DataSet出现时（ASP.NET 1.0），LINQ甚至无法实现。使用LINQ，您可以从数据库中获得类型安全和内置函数来创建/更新/删除。

Microsoft甚至试图通过LINQ to DataSet更轻松地完成转换。

Answer 4

我们即将对使用DataSet对象的现有asp应用程序进行大量更新;虽然我不期待这种痛苦，但我会坚持走下BO路线。试着让数据集工作的想法现在让我突然爆发。

我认为我们将沿着LINQ路线走下去并使用轻量级实体对象。

Answer 5

我工作的公司也大量使用DataSet，同时还有业务层。 BL主要从DB加载数据集。

我个人不喜欢这种做法。还有一种做法是在加载之后/保存之前直接修改数据集，以满足这里和那里的一些直接需求。对我而言，它确实违反了业务对象的想法，但它就是如何完成的。

ORM框架可以为您节省大量时间，尤其是在具有大量具有类似按钮和操作的视图的企业应用程序中。

但它也很容易失控。从那时起，它将慢慢变成一团糟。

在正确的情况下使用时，这两个选项都很好。只是不要混合它们。决定以一种方式做到并遵循它。

Answer 6

Mark Brittingham的答案对于两层应用程序来说是准确的。但是，如果我想使用服务层呢？ DataSet是可序列化的。键入的数据集可以节省编写自己对象的时间。类型化数据集是可扩展的。 Linq to Entities有性能问题，Linq to SQL现已死亡。 Linq到DataSet将始终是一个选项。

我将使用Typed DataSet和多层架构来节省时间和组织代码。我尝试过手工编码的BO，额外的时间和维护时间是不值得的。