Do you use DataSets or create your own business objects?

In .NET, there are 2 ways to pass data through the layers of your application. You can:

• Use DataSet objects, OR
• Write your own custom business objects

There are 2 very different opinions on this matter amongst .NET developers...

✅ The pros of the DataSet object:

• Code Generation - Strongly typed DataSet objects can be created automatically in Visual Studio. Custom business objects must be laboriously coded by hand.
• CRUD functionality DataSets - When used with data adapters, can provide CRUD (Create, Read, Update, Delete) support. You must manually implement this functionality with custom business objects.
• Concurrency - Support for concurrency is part of the DataSet object. Again, you must implement this yourself in a custom business object.
• Data binding - It is difficult and time-consuming to write custom business objects that are compatible with data binding. The DataSet object is designed for data binding.

✅ The pros of Custom Business Objects:

• Better performance - The DataSet object is a very heavy object and is memory-intensive. In contrast custom business objects are always much more efficient. Business objects are usually faster when manipulating data, or when custom sorting is required.
• Business objects allow you to combine data storage (NOT data access) and business logic (e.g. validation) in the one class. If you use DataSet objects, these must be in separate classes.

Microsoft's official word on this matter is explained in Designing Data Tier Components and Passing Data Through Tiers.  

The Case for Business Objects

At SSW we mostly choose datasets as we believe you get more for free. However all the the features you get in the dataset can be manually coded up in business objects.

E.g. For business objects you must manually code up the bindings, with datasets however you may use the designer for binding straight after designing the dataset. This layer should be code generated - so it doesn't matter much.

In Visual Studio, binding to business objects is supported in which case we might be swayed to use business objects.

Exception: Real complex forms say 500,000 lines of C# code

Datasets are a tool for representing relational data in an object oriented world. They are also slower across networks. Datasets are fantastic for maintenance forms (an editable grid with a couple of checkboxes and text boxes and a save button), but terrible for real complex forms. In a complicated scenario you might have a Customer object. An Order form has a reference to this customer object that it uses to display. When a process is run on the Customer invoked from the Order, you can simply pass a reference to the customer, and if something changes, fire an event back to the Order. If datasets were used, you would be either passing datasets around (which some may say is not very safe, or good OO) or pass an ID around and have the process load the data again.

Also it appears.NET 2.0's BindingList makes binding extremely easy along with IEditableObject. But in most cases, you don't even need to implement these.

Rocky Lhotka recently appeared on a .NET Rocks! episode and they had a big discussion of business objects versus datasets. The use of either must change on a case by case basis. Datasets do allow you to get more for free, but if one day management decide you need to do something a little out of the ordinary, there will be problems. In contrast, business objects take longer to write (this can be minimized with a good code generator and custom templates), but stand the test of time much better than Datasets.