тестирование привязки wpf

Question

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

Я читал блог Джереми Миллера достаточно, чтобы видеть, что у него есть проблемы с привязкой данных (даже с wpf) и обходит его, но я никогда не видел ясного примера того, как он это делает.

Мне нравится то, что я вижу до сих пор с возможностями рендеринга и компоновки wpf, но я просто не уверен в технологии привязки данных MS. Мой вопрос заключается в том, есть ли у кого-либо причины, почему привязка данных настолько хороша в wpf, что вы можете легко разделить проблемы и протестировать их, а если нет, то какова основная идея, которую вы используете в качестве альтернативы?

Answer 1

Я не хочу говорить за Джереми, но я считаю, что его говядина с привязкой данных меньше связана с привязкой и больше о том, как она приводит к трудному отладке/тестированию/поддержанию кода. Это, безусловно, относится к WPF/SL, когда вы включаете свои привязки в XAML, потому что они могут разрываться, не зная об этом до выполнения (и, возможно, даже не тогда). Хороший свободный интерфейс может стать обязательным для абсолютного удовольствия писать, отлаживать и поддерживать. Это была одна из моих мотивов для написания Truss.

Однако выполнение привязки данных в коде может привести к нарушению совместной работы дизайнера и разработчика. Blend не выполняет код, когда дизайнеры открывают UserControl или что-то еще. Поэтому любые привязки, написанные как код, не будут подключены.

В идеальном мире мы не будем вынуждены выбирать между ремонтопригодностью и совместной работой дизайнеров. Но это похоже на то, что сейчас происходит.