Визуализация истории бизнес-объекта

Question

В моем текущем проекте есть бизнес-объекты, которые со временем меняются. Объекты могут иметь будущие изменения, а также прошлые изменения. Одной из моих задач является создание средств просмотра и редакторов для этих объектов, которые позволяют пользователю видеть его состояние в любой момент в прошлом или будущем. Изменения довольно просты: одно или несколько значений свойств были изменены / будут изменены в определенный день.

Я хотел бы дать пользователю простой способ увидеть это. Как минимум, мне нужно разрешить пользователю перемещаться вперед и назад по истории объекта. Я также хотел бы показать предыдущие / следующие значения (если таковые имеются) каждого свойства, если бы я мог сделать это, не перегружая и не отвлекая. И, наконец, было бы здорово, если бы был какой-то визуальный способ показать сложность истории объекта, например, «график времени» или что-то еще. Это C # 3.5 в формах Windows или WPF. Все идеи приветствуются. Спасибо.

Еще одна вещь: есть ли шаблоны или лучшие практики для кодирования объектов с измерением времени?

Еще раз спасибо.

Answer 1

Несколько мыслей, которые могут или не могут помочь, так как я думаю, что я как бы проецирую свои собственные проекты на ваши вопросы ...

Если данные являются числовыми, рассмотрите графическое представление с использованием компонента построения диаграмм. Пользователи любят графики.

Я много работаю с данными времени, которые можно со временем пересматривать. Итак, представьте, что у вас есть ящик с пивом, и вы планируете его потребление в течение недели. По мере прохождения недели и измерения фактического потребления вам может потребоваться пересмотреть план на оставшуюся часть недели: альтернативный текст http://www.sulix.com/beergraph.png

так что более ранние предположения становятся более тонкими и легкими, поскольку они отступают во времени. Конечно, в зависимости от характера ваших данных, это может не применяться.

Если вы еще этого не сделали, посмотрите книги по визуализации от Tufte. Они полезны для стимулирования мыслей. Особенно приятно это Визуальное отображение количественной информации

Также, если измерение времени сильное, используйте UTC, чтобы избежать проблем, связанных с переходом на летнее время (если вы находитесь в месте, где оно действует). Преобразование в «местное время» в пользовательском интерфейсе проще, чем его сохранение и учет DST.

Что касается передовых методов кодирования данных временных рядов, я думаю, что это сильно зависит от их характера. Если они являются более типичными «бизнес-объектами» (например, личность), то я бы сохранял версионные данные в БД, а в вашем DAL предоставлял способ извлечения объекта с параметром «As Of Datetime», так что вы можете посмотрим, как это выглядело в определенное время. Если, с другой стороны, это что-то вроде почасового подсчета трафика на улице, то, вероятно, было бы более разумно иметь «уличный» объект, который имеет набор «ежедневных подсчетов трафика».

Answer 2

Я думаю, что один из самых чистых примеров того, чего вы пытаетесь достичь, можно найти здесь, в stackoverflow. Просмотр истории изменений вашего ответа.

Answer 3

В общем, то, о чем вы говорите, это наличие «мета-объекта»; то есть некоторый объект, который отслеживает ваши бизнес-объекты и который обеспечивает согласованный способ запроса прошлых и текущих значений состояния. В общем, это подразумевает точное описание ваших «бизнес-объектов», которое действительно превращает их в бизнес-данные. По сути, вы говорите о том, что просто переносите то, что вы считаете «бизнес-объектами», в конец «бизнес-данных». Это конечно возможно; Я подозреваю, что только это изменение в перспективе может помочь вам в этом процессе.