blah!bLaH!BLOG!!

Are you a Business Object person, or a DataSet person?

.. I say screw both, lets go commando!!

Posted on 6/30/2006 @ 8:52 PM in #Vanilla .NET | 12 comments | 7659 views

What is a Business Object:
Business objects are object representations in a computer program that abstract the logical entities in the specific business domain, that the program is being written for.

Practical Example:
For instance, if you are an insurance company, your business objects could be classes that represent a Policy, Premium, Payment Plan etc.

Advantages of representing your data as business objects -

1. Your customer understands a "Policy", not a DataSet or a DataTable. This allows you to abstract and communicate what you as a programmer see on your screen more effectively with the end customer.
2. Catching, isolating, and debugging rogue data is easier - because the logical information for a particular business entity is all segregated as one serializable instance, which does not need an underlying database to live and exist.
3a. You have the ability of encapsulating behavior of the data in the data itself. That approach allows you to embed logic inside business objects, so it doesn't have to live in every tier of your architecture.
4. You can subject your objects to XMLSerialization and move away from Object thinking to Schema thinking - very necessary for exposing your objects via web services, or to platforms other than .NET.
5. You can implement the translation of business objects to relational structure using a standard mechanism, though this is something that evokes wild emotions in many.
6. You can implement your business objects to all have a common behavior and implementation through interfaces and inheritance. You can enforce direct data binding and editability (is that a word?)
7. You can in VS2005, reuse your UI logic to create visualizers in debug mode for fast speedy development or just have the ability to give the programmer and customer a common communication methodology.
8. Given that your data lives as a serializable object, writing tests becomes MUCH easier, because your objects do not have to be formed as a translation between RDBMS and objects.
9. What you do with the object is your business - this gives you immense flexibility in choosing the front end UI for representing and working with your objects.
10. Your data has the ability to notify you of changes or issues - much like a living entity, something a dataset has a tough time doing.

Disadvantages of representing your data as business objects -

1. They amount to reinventing the wheel. You might do a better job than a one size fits all object - i.e. dataset, or you might do a worse job. In other words, setting up business objects involves work, and the results are only as good as the people doing it.
2. Business objects require you to worry about versioning - both data versioning, and business object versioning. This is a problem that is not easily solved.
3. Business objects require you to write the translation layer between objects and RDBMS. This is easier said than done frankly.
4. BOs require you to write a new object for a new entity - this might not be fully true as your design might encourage reuse, but you cannot beat the dataset, in which to setup the object you have to write zero code.
5. Concurrency is a bigger pain to manage using BOs. This refers to both thread concurrency and database concurrency.
6. At least in .NET 1.1, BOs are not directly databindable. You have to write the code to make that happen.
7. You lose any enhancements Microsoft may provide you with in future versions of .NET. If in .NET 1.1, you shied away from datasets, because of it's serialization problems, you probably spent a very long time getting your business objects working. Only to find out that MS fixed it in .NET 2.0.
8. Business objects either require you to write the equivalent of a data adapter, or they encourage you to fill the object as the connection is open which severely impacts connection pooling performance. Breaking this single rule can cause your application performance to degrade by about 20 times in a concurrent environment.
9. Your business objects are only as good as the underlying objects they use. Thus if you use an arraylist, you pay the boxing unboxing penalties, and removing objects from a collection is extremely expensive.

So what is the right answer? Business Objects or DataSets?

"You cannot definitively say one is a winner on the other, both have their pros and cons".

Unfortunately, I see too many folks just buy into sheep thinking, popular argument and just use business objects extensively, without understanding the repercussions fully .. but then a lot of people use 40 table strongly typed datasets as their "catch all" business objects too.

So the right answer is – “A good system architect”, and good luck finding him. Another answer could be a third party ORM – which again the challenge lies in finding someone who truly understands the product.

Or hey EDM/DLINQ is a good answer too. But you can’t have it yet.

On 8/2/2006 11:52:25 AM nick said ..

A custom class can easily be created by a generator. Using a DAL it can populate the class easily without having to write the code in one section. With 2.0 data binding is acceptable and every data source looks for IEnumerable or IDataBinding ( simple or complex respectively). A DataSet uses an IList so you can actually fine tune the storage and using the Generics the databinding requires the same or less lines than datasets. And reading can be done with a data reader or table so the connection does not have to be held.

Also. it takes 15 lines of code to set up saving and loading to the database for BO classes via reflection( which is how QLink operates in c# 3.0). And since a BO is not a singleton pattern( well I hope people aren't designing it that way) DataSets will have the same concurrency issues that BO's will. Both have to determine if employee 2 is overwriting employee 1's changes in a web application.

But, like you said. Its something an architect will decide and depending which side of the spectrum he was trained on. Usually determines what path he takes.

Just some points I thought you should know. If you have arguments against them. I would love to hear them.

Nick

On 8/2/2006 4:21:47 PM Sahil Malik said ..

Nick,

But such a generator isnt' a part of the framework, right? Sure you may even be able to find a free generator, but then when you move between jobs, chances are you won't find the same generator being moved at either end, thus that skill is not portable between contracts.

Not to mention, if Microsoft doesn't back it, then I wouldn't turn down the solution, but I would atleast be a bit cynical of it's continued support over the years. ESPECIALLY if it is Open Source :).

So yes sure there are ORM frameworks, there are also frameworks like CSLA. Many of them are quite nice, some are even backed by stable companies. But they didn't come out of MSFT, and this comment applies to that frictionless surface in zero G environment :)

Sahil Malik

On 8/11/2006 9:10:13 AM Simon Tamman said ..

I use NHibernate for my ORM. It's really nice, it does take a few months to understand how to use but it does mean that the domain of the application is much, much nicer.

The issue with datasets I find is that the storage medium of the application pollutes the domain model. Persistence of the data is not the primary concern of the application and using relational tabular objects as the domain breaks this concept.

I personally detest datasets in the application domain as it makes the code unreadable to fresh eyes and if you dont fully understand the underlying schema of the database you can get a bit lost (e.g. when you start working on an existing project that already has a massive database it can be hard to be productive quickly).

Another issue I have is with the object DataRow it breaks the concept of inheritance and separartion do to it's insistance of DataRowBuilder as an argument in the constructor.

Being unable to inherit from this object makes it difficult to extend.

You can, of course just pass a dataset into a business object as a parameter so the object just acts as a wrapper, but if you're going to this effort you may as well either write or use an ORM.

On 8/11/2006 4:45:56 PM Sahil Malik said ..

Simon - you make some good points. Please tell me, what are your pet peeves about NHibernate?

On 9/22/2006 8:40:38 PM gozh2002 said ..

Hi, can you please have a bit clarification about point 8:"fill the object as the connection is open which severely impacts connection pooling performance.".

Like the MS starterkit or new petshop, we are use execute a datareader, then loop through it to assign the value to a List<BusinessObject> collection,

I think the codes is like

using (connection = openconnection(connstr))

{

reader = executereader(sqlcmd);

foreach (reader.next())

{

//assign the reader values to a new businessobject

// add add to List<T>

}

}

Is there anything wrong with it? definately, we have to leave the connection open to get a datareader to assign an object..

On 9/22/2006 8:43:41 PM gozh2002 said ..

I also wondering, with this whole new LINQ coming, isn't it DataSet technology is a dying architecture, we are actually going to have a big change of the whole MS data application architecture. Which we currently can use NHiberate luckily.

On 9/26/2006 1:03:11 PM Arne Claassen said ..

I'm definitely a Business Object person. I just think that exposing your data the way datasets do is only going to cause you maintenance nightmares. And with the ability to bind to Business Objects as datasources, they are so much more useful now.

I played with Typed Datasets, but still would only want to use them as the BO encapsulated ORM, not the exposed entity, because even decorated with my methods, its still exposing the data at a level that is usually not appropriate.

But seeing that the typing is done with casting, not generics, I am once again leaning to staying with my own DAL. After all, if the dataset is hidden inside the BO, then the ubiquity of dataset knowledge looses a lot of its benefits anyway.

I agree that using an MS solution would be better because you get better support, transportability between projects, etc. So I hope MS will create BO tools as simple as the XSD tools, because i don't like having my UI accessing my data without having my business logic governing the interaction.

On 9/28/2006 1:27:56 AM Matt said ..

Would using both approaches be a possibility?

Using VS-generated Typed Dataset is great in saving time and code but it does have limitations (like lack of support for multiple result sets aside from the ones mentioned above). But using only Business Objects does take a long time and is error-prone.

Often, web applications need to display a list of items in a table format and display more details of a particular item when user clicks on an item from the list. Many times, the fields to display for the list of items is different (less than) from when displaying the details of one item. (Thus, the business object representing an item in a table is often different from one representing an item on a details page)

In this case would it be beneficial to use VS-generated Typed Dataset for the list of items to be displayed in a table and use Custom Business Object for displaying a single item's details especially if update/insert will mostly occur on an single items page (instead of batch update in a gridview or datagrid)?

What do you guys think? Am i just creating a huge unnecessary maintenance nightmare by doing this?

Thanks.

Matt

On 12/14/2006 12:49:22 PM Sriram said ..

Is LINQ a replacement for TableAdapters in C#3.0 framework and what is the reason behind that?.

On 2/1/2007 6:55:13 PM Gareth Goodman said ..

One size never fits all. I have seen good and bad, appropriate and inappropriate uses of generated/inherited BO's, ORM and datasets.

It often comes down to non-technical constraints. If the deadline is tight you may have to drop the richer functionality you can expose via BO's and go for a pure dataset approach; if NFR's like security, scalability etc are more important, investing time in an ORM or generated/hand-coded BO solution will pay dividends.

Horses for courses and all that. Being a good systems architect usually means having been around for long enough to spot what to use in a given situation.

On 3/10/2007 8:59:11 PM Steve said ..

TableAdapters starts with a good idea, but fails miserably, mostly because of it's closed design, you can't access important parts - ie.

ie. connection string - I need it encrypted.

ie. transactions

DLINQ seems to be a much different approach, and better. SqlMetal appears to generate classes based on your database, DLINQ gives you the ability to CRUD on it, etc...

On 2/22/2008 10:54:28 PM Johnny said ..

Are you high? No 9 is way off... There is no Boxing/Unboxing when using BO with Generic type collections. Also, Performance is not an issue with the IDataReader as opposed to the bogus data adapter.

Please post your comments:

Your feedback will be submitted for moderation, and will appear after it is approved.

Name:

Email (optional): Your email address will not be posted.

URL (optional):

Comments: HTML will be ignored, URLs will be converted to hyperlinks

Enter the text you see in the box:

Microsoft MVP

Posts By Category

Hosted By

Are you a Business Object person, or a DataSet person?

Advantages of representing your data as business objects -

Disadvantages of representing your data as business objects -

So what is the right answer? Business Objects or DataSets?

Please post your comments: