Ever since .NET came out and the practicality and advantages of OO programming became available in a straightforward, elegant language like C#, I have been bouncing back and forth between using DataSets as a psuedo-business objects or writing full-fledged objects. I’ve sinced stopped bouncing, my headache is gone, and I am ready to write about it.

To put it simply, full-fledged business objects 1) look really nice 2) provide fine-grained control and 3) provide full orientation for encapsulation and evolution. DataSets 1) are easy to build 2) provide out-of-the-box serialization 3) provide useful functionality and classes, such as collections (rows) and relationships.

To be clear, I am talking about the use of business objects vs. strongly typed DataSets as the foundation for your data payloads in an application. Illustration:

Biz Obj Approach:
public class Car {
public string Make {}
public string Model {} …
}

DataSet approach
- design a strongly-typed DataSet with the following element:
Car (will translate to a DataTable “Car”)
with the elements Make, Model, etc (will translate to corresponding columns)

There have been a ton of articles on employing either approach, but I haven’t seen too much in terms of best practice arguments for either. It boils down to an understand of the different factors around a project to make this decision:

• Is your software going to be providing or consuming external interfaces? DataSets get a point for this because they are easy to adapt to SOAP/WebServices facades.
• Do you need to employ a complex business rules engine? Custom objects get a point here, because you have full control of the creation, destruction, conversion, etc of the object.
• Do you want to rapidly prototype your application? DataSets get a point here. You can easily construct your data payloads and data access layer without cumbersome manual object mapping or taking the plunge for a full-fledged O/R Mapper.
• Are you working with an existing, well-defined data schema? DataSets again get a nod here. If you have a well-defined schema, it is easy to translate your tables and relationships to a DataSet. Modeling for pure objects sometimes becomes cumbersome.

Big downsides

It looks like I am rooted for DataSets big time. But before you flame me, we should be clear about the downsides and cautions around using DataSets as psuedo-objects.

• Can get really ugly. I have seen applications go very wrong in this way. What usually happens is that the developer starts to comingle the DataSet and Data Access Layer with the business and presentation layer. This means there are alot of very ugly and cumbersome DataSet calls right there in an .aspx code-behind or WinForms code. This is a big no-no.
• Can get really unmanageable. I have also seen applications that rely on 50+ strongly-typed DataSets for every possible data view or payload in an application.
• Can get really obtuse. Many times, developers spend too much time designing “the perfect DataSet,” which is something like the Perfect Storm, but with alot less water. They create all sorts of neat DataRelationships between tables, restrictions, constraints, etc. Then they try to use their DataSet and find out their creation is a Rube Goldberg machine twist of generated class hell.

(shrug) Is it all worth it?

Life is worth it and wonderful, DataSets often are not. Given all the above issues, can we still use DataSets effectively as psuedo-objects? Yes, we can. We simply need to follow some coding standards and foresight. I like to call them “Crap Avoidance Techniques” or CAT.

• Keep it Pretty. Like a Hollywood plastic surgeon, you need to slice carefully and keep your hands off your assistant. Tough analogy I know, but I’ll stretch for this one.
• Essentially, just make sure you keep any psuedo-object manipulation, validation, etc. in your business layer or data layer. Keep your layers sliced evenly and consistently. Never, ever start playing around with your DataTables in your code-behind. But how? Try writing some helper classes that have factory patterns to construct your DataRows. Give a multi-assembly data layer a chance, keeping your DataSet and generic helper classes away from your data provider specific code.
• Keep it Manageable. Don’t write 50 DataSets for every possible permutation of your data, especially if you have a complex schema and you are presenting report-like results to a presentation layer. You can easily create a DataView factory that poops out your data in a very nice format that is ready to bind. Save your strongly-typed DataSets for your real payload objects — those objects that are passed around and manipulated between layers.
• Keep it Clean. Don’t try to remodel your database in a DataSet. Take the slices that are used in the application. Think ahead about the object design, but don’t try to pack everything in. If you use DataViews as I’ve outlined above, you’ll find that unless you have a very complex business application, you shouldn’t have to have more than a few DataTables in a DataSet.

I know I am a little light on details here, but I wanted to get these thoughts out and hear back from the .NET community.