I'm using business objects (as opposed to DataSets/DataTables) to
contain all my data and I'm passing these to forms to populate them.
They get sent to the form's constructors and populate all the controls
onLoad, and when someone hits save, I validate all the values, then
write them back to the business object (and then down to the database).
This is fine for all simple data types like tying strings to textboxes
or labels.

My issue comes in with ComboBoxes-- specifically what is the best
methodology for handling them? Should I contain a datatable (which is
sourced from a stored procedure) in the business object that contains a
{displayvalue, datavalue} pair for the ComboBox as well as the actual
value that gets selected, or should the form be responsible for
populating the ComboBox itself and the business object just contains the
selected (and default) value?

There are advantages to each-- if I contain all the data in the business
object then it neatly separates the data from the presentation layer
entirely, but on the flip side, it clutters what should just be a data
class with something that seldom changes and isn't really relevant in an
object. For example, say the class is 'PersonData', and the ComboBox
contains a list of color's; the list of colors doesn't describe the
person at all, we just want the person's favorite color. On the other
hand, populating the ComboBox from the form itself seems to blur the
lines between data and presentation tier. Then again, if the data ever
changed substantially, the form would have to be redone regardless.

I'm just sort of stuck about this sort of thing, so I was wondering if I
could get some input from others as to how they handle this sort of
thing and maybe a few good resources for how to split stuff up into the
data/business/presentation tier.

Thanks in advance,

DS,

I ran into this exact issue for a smart client I'm developing. Being a
novice, I read and hacked around and ultimately what I came up with was
a manager class that isolates the data retrieval from the UI layer
except for the binding (which MUST happen on the main UI thread).

In a nutshell, my form calls various bind methods for different data for
each control. These methods do some queue management (basically queueing
up multiple calls) then return immediately . On the initial call to the
method, my manager requests the data from web services using BeginInvoke
calls.

The web service request returns asynchronously to a private method in
my manager that then calls EndInvoke, processes the returned data and
finally uses Invoke to call a delegate method on my main form which
performs the actual binding o the control.

I should mention that each data has its own queue stored in a hashtable.
It's probably the most inelegant solution possible but it works pretty
well for me (no nasty threadlocks).

A caveat is that my form displays before all of the data has been
fetched so the user sees some of the combo boxes populating (i.e. they
see actual text zipping through the textbox as though someone were
rapidly typing & deleting) rather than a serene interface.

Another caveat is that there is a penalty on startup (I'm fetching a lot
of data over HTTP). I used the ol' splash screen trick to mitigate.

HTH
RRB
======================

blackbox testing prerequisites:
1 white box
1 black marker