【发布时间】：2010-10-18 14:04:24
【问题描述】：
我正在考虑 ASP.NET 应用程序的数据访问。来自一家使用大量带有客户端数据集的 Windows 应用程序的公司，自然倾向于使用 DataSet 方法来处理数据。
我更喜欢业务对象方法，我不喜欢在会话中缓存 DataSet 然后应用更新的想法。
有没有人有任何经验/帮助传授这两种方法的优缺点？
【问题讨论】：
【发布时间】：2010-10-18 14:04:24
【问题描述】：
Mark Brittingham 的回答对于两层应用程序来说是准确的。但是，如果我想使用服务层怎么办。数据集是可序列化的。类型化的数据集节省了手动编码您自己的对象的时间。类型化数据集是可扩展的。 Linq to Entities 有性能问题，Linq to SQL 现在已经死了。 Linq to DataSet 始终是一个选项。
我将使用类型化数据集和多层架构来节省时间和组织代码。我已经尝试过手动编码的 BO，额外的时间和维护时间不值得。
【讨论】：
-
数据集是特定于平台的。数据集是在 .NET 1.0 时代创建的，当时 SOA 还非常不成熟。它们现在是 SOA 上下文中的反模式；更多的是代码臭而不是代码气味。不要使用它们。
我工作的公司也大量使用数据集，同时也有业务层。 BL主要从DB加载数据集。
我个人不喜欢这种方法。还有一种做法是在加载后/保存前直接修改数据集，以满足一些即时需求。对我来说，这确实违反了业务对象的概念，但它就是这样做的。
ORM 框架确实可以为您节省大量时间，尤其是在具有大量具有类似按钮和操作的视图的企业应用程序中。
但也很容易失控。从那时起，它会慢慢变成一团糟。
在正确的情况下使用这两个选项都很好。只是不要混合它们。决定以一种方式去做并遵循它。
【讨论】：
考虑在应用中设计数据层是明智之举。在 ASP.NET 应用程序中，这将帮助您标准化并大大简化您的数据访问。您将需要学习如何创建和使用 ObjectDataSource，但这非常简单。
数据访问层（使用单独的项目/DLL 构建）的另一个优点是它使单元测试更加简单。我还鼓励您构建一个业务层来完成大部分数据处理（例如，业务层将负责将 ObjectDataSources 从 DAL 拉到 UI 代码中）。这不仅可以让您封装业务逻辑，还可以提高代码的可测试性。
您确实不想在会话中缓存数据集（或 DAL 对象）！您将构建一个 Web 应用程序，以便记录修改通过唯一 ID（或其他主键规范）工作，并在进行更改时直接将更改提供给 DAL。如果您要缓存所有内容，您将显着降低应用的可扩展性。
更新：此线程上的其他人正在推广使用 ORM 的想法。由于我之前概述过here 和here 的原因，我会谨慎采用成熟的ORM。不过，我确实同意避免使用 DataSet 是明智之举。在我自己的工作中，我广泛使用 DataReaders 来填充我的 ObjectDataSources（由于我的 DAL 的设计，这很简单）并发现它非常有效。
【讨论】：
我们即将对大量使用 DataSet 对象的现有 asp 应用程序进行重大更新；虽然不期待痛苦，但还是要坚持走BO路线。现在一想到要让数据集工作就让我大汗淋漓。
我认为我们将走 LINQ 路线并使用轻量级实体对象。
【讨论】：
-
Rik - 您可能想点击我帖子中的链接，了解 LINQ 的逆向观点。即使您确实采用了它，您也应该意识到可能出现的问题。
与其他 ADO.NET 对象（如 DataReader）相比，DataSet 的效率可能非常低。我建议根据您所说的走向 BO/ORM 路线。
【讨论】：
如果您要遵循 Microsoft 的方向，那么趋势肯定是 LINQ (ORM) 与 DataSets。当 DataSets 出现时（ASP.NET 1.0），LINQ 甚至是不可能的。使用 LINQ，您可以获得类型安全和内置函数来从数据库中创建/更新/删除。
Microsoft 甚至尝试通过LINQ to DataSet 使过渡更容易。
【讨论】：