Why should you use business objects in .NET and not DataSets?
When Microsoft first came out with .NET, strongly typed DataSets were presented in every book and by many Microsoft evangelists as THE new way to persist information to the database. Microsoft launch events were held that demonstrated the “zero lines of code” capabilities of .NET using DataSets and Data Adapters (now in .NET 2.0 as Table Adapters). Developers were shown how easy it was to simply drag and drop a DataSet onto a form and bind to controls. Like a group of lemmings coders left the familiar business objects in the COM layers of VB6 & C++ and nestled up beside the new warm glow of the DataSet. All this “ease of use” is now a maintenance nightmare.
Business rules should go in business objects. The problem with DataSets is that there is no where to place business rules. The business logic inevitably ends up in the user interface layer (where it should not go). Microsoft tried to solve this problem in .NET 2.0 by adding partial classes. This did nothing to combat having the same tables in multiple DataSets across the application. If the same table, such as a customer table, was throughout the many screens, business rules would be duplicated for every instance in a partial class. An alternative to using partial classes is to create separate business objects that contain the business rules and calculations for a particular table. Although this can be done, if the business class handles complex calculated fields as in an overhead driven manufacturing quote; data synchronization between the dataset and business object is problematic at best.
Adding fields or changing the properties of a field for a table that exists in multiple DataSets means changing all DataTables and their corresponding TableAdapters. If a developer forgets to change one DataSet on a screen, that screen will bomb at runtime for the end user. Not good. In a large application, it can take a long time to track down everything that needs to be changed.
As a way to partially save an application from the pain of using a separate DataSet on every form, a shared DataSet could be created to be used in the entire application. This allows everything to be maintained in one place. Now DataSet partial classes can be used effectively. Business rule objects can interact with a single DataTable. Does this solve everything? No way.
In my personal experience with using both DataSets and business objects in enterprise applications; business objects are the clear winner for the least business pain. Maintenance cost usually usurps the initial development cost. The way to save on ongoing maintenance cost is to use business objects. If you decide to web enable your WinForm application or make your web application into a smart client, you won’t have to extract the business rules out of your user interface layer. The consensus is that it takes a much longer time to develop an application with business objects compared to DataSets. This is in part due to the thinking that business objects must be coded by hand. Persistence frameworks such as MM.NET allow developers to generate the code for business objects and then have the same zero code data binding as a DataSet. When you compare business objects to DataSets, coders should think about the real business advantages in the list below.
Undeniable Advantages of Business Objects vs. DataSets
- DataSets are Microsoft specific. If you need to pass them into a non-Microsoft, i.e. Java web service you will need to create a separate business object to pass to it. In large organizations, technology choices are like a light switch; one IT manager comes in and loves Java and the next manager comes in and switches the company standard to .NET. Be ready to support both legacy and future switches by having generic business objects.
- Some department in your company has a spreadsheet or an Access database of information that should be in the main company system. Business objects allow business rule validation before it is saved to the database. Nothing is worse than having users upset due to runtime errors resulting from bad imported data.
- Business objects have better encapsulation and extensibility than their DataSet counterparts. Code reuse lowers project costs.
- Code generators such as MM.NET , CodeSmith, MyGeneration, and can generate all the persistence layers for an application. They actually generate more capabilities than what is built into DataSets. The templates that generate the output can be customized. The code generators also allow regeneration when the database schema changes. Custom code is preserved through partial classes. Unless you want to modify the .NET Framework, you’re not going to be able to modify the output of how the DataSet is generated.
- DataSets almost beg the developer to place the business logic in the user interface layer. Having a business rules region in a business object woos the coder into placing the business rules in the proper place. This lowers the cost of putting a different user interface on the application.
- Using a DataReader to populate Business Objects has 30x more performance than using a TableAdapter to fill a DataSet. End users will have a more positive experience when the performance of the application is considered when the application is designed. This is in contrast to deploying the application and then scrambling to improve the performance for angry users. If it is a commercial application it can mean the difference between a lot of sales and very little sales.
- Business objects are easier to regression test. Having some of the business rules in the database, some in a partial class for a DataSet, and some in the user interface layer makes it much more difficult to perform regression testing. Unless your company has forked out the loot for a high end user interface testing tool such as WinRunner or Rational Robot, defects will get through to the end user. Testing frameworks such as NUnit or Microsoft Test allow a high quality product to reach the end user.
When considering DataSets vs. business objects, remember that a well designed application using business objects will reduce future headaches in the maintenance of the application which ultimately lead to lower support costs.
Author: Greg Finzer
Date of article: 12/29/2006
This article is copyrighted © 2006 by Kellerman Software. All rights reserved. Permission is hereby granted to link to this article. Please contact info@kellermansoftware.com for pricing on reprinting this article in either online or print publications.
