is data binding instead of loading data table in my own code a bad practice for a readonly data grid view?

I am using DevExpress GridView here, but I am guessing that the issue is relevant more broadly, at least in the WinForms world of data-driven apps.

At present I am usually doing data binding when displaying data freshly loaded from database and this is also a common practice in the code base I inherited. But, often enough I am unable to format (alter the text) the bound data using format strings, so I end up having to hide the poorly formatted columns, add unbound columns with similar names and dynamically populate them with formatted data from the hidden ones (the previous programmer did even worse, he routinely formatted inside stored procedures, ugh!). I get the nagging feeling that maybe this approach just sucks.

So I am thinking about an alternative - suppose I create my own FormattableGridView especially for the purpose of displaying readonly data. All columns will be unbound and populated dynamically from the data table, while preserving the same column names as the data table开发者_如何学JAVA itself. If I want to format some columns, some rows or in a zig-zag fashion through the grid, I just do it directly dynamically, because the unbound grid can be messed with just as easily as a 2-dimensional array.

This might sound nice and good, but apparently data binding of grid views (most of which presumably are also readonly) is a pretty common thing. I find it mentioned online all the time. So, are there drawbacks that I am ignorant of to the pattern I delineated above that keep it from spreading? Or is the data binding in itself an unwise pattern in these cases whereas what I described is indeed the better way?

EDITED:

ok, so in part answering my own question, further research uncovers DevExpress CustomColumnDisplayText event apparently specifically intended for unrestricted formatting of databound grids. Perhaps similar events exist in gridview components from other similar frameworks. Ok, so maybe that indeed is the proper pattern, although the event-driven way of handling this issue feels a bit weird.

The grid publishes the GridView.CustomColumnDisplayText event which can be used to format wrongly formatted values. I think, that this is the best and easiest solution for this task.