Composition, Databinding, DataGridViews, and lots of gray hair

Composition, Databinding, DataGridViews, and lots of gray hair

Old forum URL: forums.lhotka.net/forums/t/2551.aspx


bgilbert posted on Monday, March 19, 2007

I'm trying to get my head around the best practice for exposing a contained object to data binding. Here's a simplified view of the scenario:

I have a Shifts class (ERLB) which contains Shift (EditableChild) objects.
I have a WorkedShifts class (ERLB) which contains WorkedShift (EditableChild) objects. Inside the WorkedShift class, I contain a shift object, like so:

Private _shift As Shift = Shift.NewShift

Public Property Shift As Shift
Get
Return _shift
End Get
Set(ByVal value As Shift)
_shift = Value
End Get
End Property

In the DataPortal routines, I use _shift.Id to persist the Id value to the workedShifts table.
Question #1: In the DataPortal_Fetch for workedShift, I create a new shift object and fill it's properties with values returned from the sproc via a join. Is this a valid way to do it? Should I, instead call the shift class's GetShift method based on the shiftId for each workedShift? This guarantees accurate filling of shift objects, but involves a round-trip for each record.

I don't want the workedShift class to need to know the internal workings of the Shift class. This makes some amount of sense to me, until I get to the UI.

I have a DataGridView bound to a BindingSource, bound to workedShifts. The Shift column is a combobox, filled with Shift objects. I cannot seem to get the DGV to behave iteslf. It cannot seem to reconcile the shift objects in the combobox with the shift objects returns by the workedShifts bindingSource.

What is the best approach to these issues? Should I abandon binding to the shift object in the workedShifts class and expose the shiftId? Unbind the combobox?

Any help would be appreciated.

Barry

RockfordLhotka replied on Monday, March 19, 2007

1) It is not ideal to set properties when loading an object, because the resulting object is marked as dirty, when in fact it certainly isn't. It is better to call a Friend/internal fetch method on that object, passing in all the data it needs, and allowing that object to set its own fields.

2) You are probably best served by exposing both a ShiftId property and a ShiftList property. You can use ShiftList to populate the combobox, and ShiftId as the bound property. As long as each Shift object in ShiftList also has an Id property, data binding can match them for you, so the user only sees the human-readable value. The NameValueListBase exists to help simplify this sort of thing.

bgilbert replied on Monday, March 19, 2007

Rocky,
I came to the same conclusion regarding point #1.

I've tried your suggestion to fill and expose a ShiftList property, but still no cigar. I get DataGridView errors indicating that the value cannot be found in the combobox's list. If these were simple types, it would fail the same way if the value is not available in the list or if the types were different. I wonder how the BindingSource compares values when they are complex objects?

No doubt that this would be handled by .Net much better if I were using ADO objects.


Barry

Copyright (c) Marimer LLC