Я использую DevExpress GridView здесь, но я предполагаю, что проблема актуальна в более широком смысле, по крайней мере в мире WinForms приложений, управляемых данными.
В настоящее время я обычно делаю привязку данных при отображенииданные, недавно загруженные из базы данных, и это также распространенная практика в кодовой базе, которую я унаследовал.Но, довольно часто, я не могу отформатировать (изменить текст) связанные данные, используя строки форматирования, поэтому мне приходится скрывать плохо отформатированные столбцы, добавлять несвязанные столбцы с похожими именами и динамически заполнять их отформатированными данными из скрытых.(предыдущий программист делал еще хуже, он обычно форматировал внутри хранимых процедур, тьфу!).У меня возникает неприятное ощущение, что, возможно, этот подход просто отстой.
Так что я думаю об альтернативе - предположим, я создаю свой собственный FormattableGridView специально для отображения данных только для чтения.Все столбцы будут связаны и динамически заполняться из таблицы данных, сохраняя при этом те же имена столбцов, что и сама таблица данных.Если я хочу отформатировать некоторые столбцы, несколько строк или зигзагообразно через сетку, я просто делаю это напрямую динамически, потому что несвязанная сетка может быть испорчена так же легко, как 2-мерный массив.
Это может звучать красиво и хорошо, но, очевидно, привязка данных представлений сетки (большинство из которых предположительно также доступны только для чтения) является довольно распространенной вещью.Я нахожу это упомянутое онлайн все время.Итак, есть ли недостатки, о которых я ничего не знаю, в схеме, которую я обрисовал выше, которая препятствует его распространению?Или связывание данных само по себе является неразумной схемой в этих случаях, тогда как то, что я описал, действительно лучше?Событие DevExpress CustomColumnDisplayText, по-видимому, специально предназначено для неограниченного форматирования сеток с привязкой к данным.Возможно, подобные события существуют в компонентах gridview из других подобных структур.Хорошо, возможно, это действительно правильный шаблон, хотя управляемый событиями способ решения этой проблемы кажется немного странным.