我正在考虑 ASP.NET 应用程序的数据访问。来自一家使用大量带有客户端数据集的 Windows 应用程序的公司，自然倾向于使用 DataSet 方法来处理数据。
我更热衷于业务对象方法，我不喜欢在 session 中缓存数据集然后应用更新的想法。
有没有人有任何经验/帮助来传递两种方法的优缺点？
最佳答案
考虑在应用程序中设计数据层是明智之举。在 ASP.NET 应用程序中，这将帮助您标准化并极大地简化您的数据访问。您将需要学习如何创建和使用 ObjectDataSources，但这非常简单。
数据访问层(使用单独的项目/DLL 构建)的另一个优点是它使单元测试更加简单。我还鼓励您构建一个业务层来完成大部分数据处理(例如，业务层将负责从 DAL 中提取 ObjectDataSource 以交给 UI 代码)。这不仅可以让您封装业务逻辑，还可以提高代码的可测试性。
您不想在 session 中缓存数据集(或 DAL 对象，就此而言)!您将构建一个 Web 应用程序，以便记录修改通过唯一 ID(或其他主键规范)进行，并在更改完成后直接将更改提供给 DAL。如果您要缓存所有内容，则会显着降低应用程序的可扩展性。
更新:此线程上的其他人正在推广使用 ORM 的想法。出于我之前概述的 here 和 here 的原因，我会谨慎采用成熟的 ORM。不过，我确实同意，避免使用 DataSet 是明智的。在我自己的工作中，我广泛使用 DataReaders 来填充我的 ObjectDataSources(由于我的 DAL 的设计，这是微不足道的)并发现它非常有效。
关于ASP.NET 数据集与业务对象/ORM，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/734560/