Hi,

In architecting our distributed application we're still waffling between having the BO layer pass back a typed dataset to the presentation layer vs. the BO passing a serialized instance of itself to the presentation layer.

Firstly, it seems with datasets we have to go w/ strongly typed datasets. Otherwise, you lose too much (compile time catching of bugs, intellisense, etc.). With typed datasets, it also seems we'll be managing many source files for one BO; e.g. BO class definition & BO dataset schema. (this is a minor issue)

The biggest pluses for datasets seems to be "that's what MS is pushing", ease of databinding, particularly in datagrids and consumability in reports. We've hade a few issues w/ binding grids to our collections of BOs (had to create converters, etc.).

Currently, our BOs have properties that are actually objects as well; e.g. type StringProperty so that the property object actually has a value, and other meta data like a caption, required?, etc. This doesn't seem possible w/ typed datasets. Well, I guess we could subclass typed datasets to add some meta data scheme. However, this then causes a disconnect between columns in data tables and the associated meta data - the front end would need to know to look in the other table for the meta data.

Also, our requirements include the need for column level security. With strongly typed datasets, I don't see how we can pass back a table sans a few columns. One option might be to NULL the values in the columns, but what if the BO needs the real values for some calculation, etc.? We don't want to defer security enforcement to the presentation layer as we want to expose this as a service and cannot guarentee the consumer will follow the rules. With properties, we could simply throw a security exception on access if the consumer doesn't have rights. Internal use of the property would access the field directly rather than through the property.

Thanks for your time and comments,

Mark