I have studied the example in the Jump Start on specifying which columns to display from the BO in a mmDataGridView, and I have a little issue here...

Obviously, we want to do as little work in the UI objects as possible, and shove more of the coding effort into the BO, so that if I re-create my app in WPF or ASP or WinForms (or whatever comes out next), it will require as little work as possible to re-write the UI. RIGHT?

Well then, why would the example teach me to hard code all those grid columns to specific data columns, rather than building a BO method for the desired data-column presentation that I want for the grid (i.e. GetWhateverRecords() type methods in the BO that call stored procs). You would need a BO method for that would pull ONLY the columns that I want to display in the grid. That way you could just leave the grid columns alone and let it show all the columns in the BO? The point is that the BO method determines the columns to show, not the UI grid object.

Yes, I might have a few more Get...() calls in my BO to cover all the possible column views that my app will need, but as I re-write the UI in the future to keep chasing all the UI platforms Microsoft keeps coming up with, the BO will be ready.

Plus, if I want to add or remove columns to display in the grid, I change the BO method, not the UI grid object. Isn't this one of the basic premises of this whole "put your logic in the BO not the UI" religion?