DataSet vs Business Objects?

Ricky White
Ricky White used Ask the Experts™
I have a C#.Net project that was created by somebody else.
It appears to use Business objects(Lists,Sorted Lists, Collection of objects, etc) and doesn't use much of typical ADO.Net (Datasets, datatables, Datarows etc). Although there is a data access layer that executes the SQL queries.

My question is, is one of these approaches considered better than the other? Was Business Objects used in the olden days and ADO.Net is a newer technology?

I would like to follow the best practice so please advise if you also use Business Objects as opposed to Datasets and why?


Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
well i would only use dataset if i have to write the data back to sql. Otherwise I would ask my datareader to fetch me the data and definitely convert the data to my Business Objects or DTO(Data Transfer Objects).

Its always good to work with data represented in the form of concrete type rather than a Abstract Type like DataRow where items are represented as collection of columns which can be read by an index or name.

Suppose your DB returns list of customers with ID, Name and Address Fields.
Now If you make a Customer Business Object like this:-

class Customer
public long Id{get;set;}
public string Name{get;set;}
public string Address{get;set;}

Now if you convert all your rows in Customer Type and store Customers returned from DB in generic list of customers, this list will contain a strongly typed collection of your customer rather than using Datatable which represents every customer item as DataRow which is collection of DataColumn with each having name and value as object.

So all in all working with BO/DTO makes your collection type safe and compile time safe too..
BO have always been used, though probably going under different definitions. Datasets, as the article you referenced says, were introduced as an improvement in the design of BO by reducing code thus developement time (and costs), however again as pointed out in the article, the resultant maintanance overhead that became associated with projects developed using datasets et al for large complex projects meant that it was actually not meeting the efficiency dev time (read costs) that it was meant to deliver.

With regard to fashioning BO's with collections et al, I there is consensus that though initial dev timescales are large, (with relevant skill-sets) maintanance and updating is easier.

Thus for my sixpence, and within the limits of your definitions for BO's and Dataset's, I'd recomend BO's.

My question is, is one of these approaches considered better than the other? Was Business Objects used in the olden days and ADO.Net is a newer technology?

This is something to do with layering of your application.

N-Tier applications is breaking up an application into tiers, to create a flexible and reusable application. In genaral most medium size to large size of application have the following layers or tiers : 1. Presentation 2. Business Logic 3. Data Access and 4. Database Layer. Each of these layers serves a dinstinct task.

It is a good idea to split an application logic do different layers because of complexity and extensibility.

I would like to follow the best practice so please advise if you also use Business Objects as opposed to datasets and why?

If you are developing a medium to large scale of application then it would be better to use N-tier application, if you are developing small size application, you can use single layered application, but that does not mean you can't use business object. It's a matter of application architecture.

Please read:
Top Expert 2015
Business objects over DataTables and Datasets anytime... if you have to time to code them.

DataTables and Datasets are wonderful tools for fast development, but they are bloated with features that you might not use. The size of a DataTable can be many times the size of the same thing in a collection. For each row, a DataTable requires many extra properties that the collection does not have in order to work, and many of those might not be used in your application. Same for the columns, the DataSet adds to the count.

In your business objects, you store only the information that you really need, with a greater versatility. For instance, in my current application, i need to work with decimal measurements displayed that have to be displayed as fractions (3/16, 7/32). This would be hard to work with in a DataTable if you wanted to display the data in a grid set for editing for instance. A simple conversion routine built into my class system gets rid of all the difficulties. And if the classes are designed and documented properly, you usuallly end up with applications that are a lot easier to maintain.

Classes are also a lot easier to work with. Having an ID property thas is and Integer and a CustomerName that is a String is a lot easier and brings more performance than having to cast all the time from the Object types that you get in a DataTable.

The business objects can be shared between many applications. If you ever need to change something in the structure of the database, or switch to another database, adapting the dll that contains the business object would be a lot easier than having to make the changes in all the applications.

This being said, the time you need to develop the business objects will be a lot longer that it would be with ADO.NET objects. And some of that time will be to recreate things are are already there in a DataTable. In the long run, this is usually offsetted by the time gained in maintenance. But if your customer or boss does not understand the long run gain (most don't), he will not like you taking the extra time required before he sees the first results of your work.
AndyAinscowFreelance programmer / Consultant

You have asked another qestion recently:

You might want to have another look at my comments there (and the links) - you didn't understand what you had been told after all.

You are confusing different layers (business vs data) in how an app is designed.


Thanks All!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial