Данные времени проектирования в WPF / Silverlight - как правильно использовать классы-оболочки? - PullRequest
0 голосов
/ 23 октября 2010

Я сталкиваюсь с проблемой наилучшей практики "поддержки времени проектирования".Я использую PRISM, и мои объекты создаются DI-контейнером.Давайте предположим следующий простой сценарий:

У меня есть рабочий процесс объекта.Этот рабочий процесс имеет несколько свойств, и существует WorkflowProvider, который предоставляет список рабочих процессов.

Если я создаю ListView, у меня нет проблем.Я использую объект MainApplication в качестве контекста данных времени разработки, и мой список привязывается к свойству "WorkflowList".В моем реальном приложении я могу установить контекст данных для соответствующей реализации.

Но я не знаю, как обрабатывать одно представление рабочего процесса !

Обычно я бы создал объект рабочего процесса в качестве контекста данных времени разработки .Но мой объект рабочего процесса не может быть создан самостоятельно (с пустым конструктором), он должен быть свойством, например, моего WorkflowProvider.Итак, один из подходов, который я использовал в прошлом, был такой:

  • Написать фиктивный подкласс для рабочего процесса
  • В пустом конструкторе фиктивного объекта получить "реальный рабочий процесс"
  • Назначьте все свойства «реального рабочего процесса» свойствам моего фиктивного класса
  • Используйте экземпляр фиктивного рабочего процесса в моем представлении времени разработки

Единственная причина для этогоявляется то, что я не знаю, как установить контекст данных времени разработки для свойства, а не объекта.Это возможно, или есть какой-то другой способ, который имеет смысл.Чтобы уточнить, я знаю, что мог бы связать, например, свою сетку в моем «представлении подробностей рабочего процесса» со свойством, но тогда я не мог использовать представление подробностей без изменений в качестве DataTemplate в моем представлении списка.Я надеюсь, у вас есть моя проблема: -)

Крис

1 Ответ

0 голосов
/ 23 октября 2010

Хорошо,
Как часто, немного размышлений и правильное предположение решили мою проблему:

d: DataContext = "{Binding WorkflowProvider.CurrentWorkflow}"

делает свое дело и будет игнорироваться в сценариях реального времени ...

...