ASP.NET 数据集与业务对象/ORM [英] ASP.NET DataSet vs Business Objects / ORM

问题描述

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

I'm thinking through data access for an ASP.NET application. Coming from a company that uses a lot of Windows applications with Client Data sets there is a natural dendancy towards a DataSet approach for dealing with data.

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

I'm more keen on a Business Object approach and I don't like the idea of caching a DataSet in the session then applying an update.

有没有人有任何经验/帮助传递这两种方法的优缺点?

Does anyone have any experience / help to pass on about the pros and cons of both approaches?

推荐答案

考虑在应用程序中设计数据层是明智之举.在 ASP.NET 应用程序中，这将帮助您标准化并大大简化您的数据访问.您将需要学习如何创建和使用 ObjectDataSource，但这非常简单.

You are smart to be thinking of designing a Data Layer in your app. In an ASP.NET application this will help you standardize and pretty dramatically simplify your data access. You will need to learn how to create and use ObjectDataSources but this is quite straightforward.

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

The other advantage of a data access layer (built using a separate project/DLL) is that it makes Unit testing much simpler. I'd also encourage you to build a Business Layer to do much of the processing of data (the business layer, for example, would be responsible for pulling ObjectDataSources from the DAL to hand to the UI code). Not only does this let you encapsulate your business logic, it improves the testability of the code as well.

您确实不想在会话中缓存数据集(或 DAL 对象)！您将构建一个 Web 应用程序，以便记录修改通过唯一 ID(或其他主键规范)工作，并在进行更改时直接将更改提供给 DAL.如果您要缓存所有内容，您将显着降低应用的可扩展性.

You do not want to be caching DataSets (or DAL objects, for that matter) in the session! You will build a Web app so that record modifications work through a Unique ID (or other primary key spec) and feed changes directly to the DAL as they are made. If you were to cache everything you would dramatically reduce the scalability of your app.

更新:此线程上的其他人正在推广使用 ORM 的想法.由于我之前概述的原因，我会谨慎采用成熟的 ORM 这里和这里.不过，我确实同意避免使用 DataSet 是明智之举.在我自己的工作中，我广泛使用 DataReaders 来填充我的 ObjectDataSources(由于我的 DAL 的设计，这很简单)并发现它非常有效.

Update: Others on this thread are promoting the idea of using ORMs. I would be careful about adopting a full-blown ORM for reasons that I have previously outlined here and here. I do agree, though, that it would be wise to avoid DataSets. In my own work, I make extensive use of DataReaders to fill my ObjectDataSources (which is trivial due to the design of my DAL) and find it to be very efficient.

这篇关于ASP.NET 数据集与业务对象/ORM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！