ASP.NET 数据集与业务对象/ORM

我正在考虑 ASP.NET 应用程序的数据访问。来自一家使用大量带有客户端数据集的 Windows 应用程序的公司，自然而然地倾向于使用数据集方法来处理数据。

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

有谁有任何经验/帮助传达这两种方法的优缺点吗？

你很聪明地考虑在你的应用程序中设计一个数据层。在 ASP.NET 应用程序中，这将帮助您标准化并显着简化数据访问。你will需要学习如何创建和使用 ObjectDataSources，但这非常简单。

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

You do not想要在会话中缓存数据集（或 DAL 对象）！您将构建一个 Web 应用程序，以便通过唯一 ID（或其他主键规范）进行记录修改，并将更改直接提供给 DAL。如果你要缓存所有东西戏剧性地降低应用程序的可扩展性。

更新：该线程上的其他人正在推广使用 ORM 的想法。由于我之前概述的原因，我会谨慎采用成熟的 ORMhere https://stackoverflow.com/questions/458802/doesnt-linq-to-sql-miss-the-point-arent-orm-mappers-subsonic-etc-sub-opti and here https://stackoverflow.com/questions/640004/is-linqtosql-powerful-enough-isnt-a-more-powerful-but-equally-fluent-interface. I do不过，同意避免使用数据集是明智的。在我自己的工作中，我广泛使用 DataReaders 来填充我的 ObjectDataSources（由于我的 DAL 的设计，这很简单），并发现它非常高效。