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.
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.