the ‘bee log

One of the chief problems the community has with DataSets is that they’re not as easily composable (flexible) as domain models. That is, they represent tables, rows, columns, and not what you’d want in a “pure” OO design: graphs-by-purpose.

So is every object graph a dataset? Is every table a class? Is every row an object? Is every column a property? Hardly… Does DataBinding save a lot of code? Does a typed DataSet provide a rich and stabile structure for you to program against for minimal effort? Absolutely…

What we’re seeing emerge in our codebase is a sensible approach. We have domain objects. We have datasets. Sometimes we have datasets that bear a relationship to each other.

The state model of CAB buys us composition and reduces the amount of code we have to feed and take care of. It lets us build up a “state collection” that may contain domain objects (AttributeMetadata), DataSets, primitive types, GUID values, anything. This is a state model metaphor easily comparable to ASP.NET’s HttpSession… a model that has its dangers, but is pretty convenient. The technical risks associated with this model are somewhat diminished considering the application is single-user (smart client) and can mitagated by developing guidance around the use of constants and generalzing WorkItem lifecycle management through a common WorkItemExtension.

Of course, WorkItem state is injected into child workitems. You need to be intentional about our WorkItem hierarchy and where the state is set. Something we’re discovering very early on.