Упрощение реализации INotifyPropertyChanged

Объект, корректно реализующий интерфейс INotifyPropertyChanged оказывается “наблюдаемым” (observable), т.е. изменения его состояния могут легко отслеживаться подписчиками и, например, отображаться на визуальных компонентах в актуальной форме.

Однако при реализации этого интерфейса следует явным образом указывать строку - имя свойства, которое было модифицировано. Это чревато ошибками.

Опять же, довольно много кода приходится писать по нескольку раз.

Общественность =) неоднократно предлагала различные решения этой проблемы – от построения прокси-INotifyPropertyChanged вокруг POCO-объекта и патча бинарников с помощью PostSharp-а до различных структур, упрощающих привязку.

Я, естественно, пошел своим путем, т.к. во всех вариантах меня что-то не устраивало =)

В итоге остановился на том, что создал интерфейс и пару реализаций (для отдельного свойства и для списка), которые можно увидеть здесь, здесь и здесь. Пример использования можно увидеть здесь. Как видно, boilerplate-а поубавилось.

Недостатки: текущим реализациям надо передать имя свойства и их события надо перенаправить классу-модели.

Первое можно забороть с помощью Reflection-а (смотреть, какое свойство вызвало метод Set()), второе – сделать класс ModelBase, а в нем метод, настраивающий подписку для всех свойств разом.

Но я пока не решил, надо ли мне это =)

Fluent data binding

В .NET есть возможность привязывать свойства графических элементов к свойствам некоторого объекта-модели.

В результате привязки изменения в одном месте отражаются в другом. Например, редактирование текста в TextBox-е может автоматически обновлять поле Text в модели. Или изменение в модели флага , привязанного к свойству Enabled может блокировать элемент управления.

Сампл можно посмотреть здесь (показана только т.н. “простая привязка”, “сложная” делается ), хотя, уверен, ни для кого ничего фундаментально нового в этом нет.

Чем это хорошо? Хорошо это тем, что существенно уменьшается объем кода, связанного с отображением данных.

Чем это плохо? Плохо это тем, что свойства как модели, так и представления кодируются строками. Со всеми вытекающими отсюда следствиями, от которых и велемудрый R# не всегда защитит. Пытается защищать от этого графический редактор в VS,  но, опять же, только частично (к тому же, я лично предпочитаю писать код, а не тыкать мышкой).

Работая над Syringe, я решил защититься от возможных проблем со строками и набросал небольшой набор классов и методов-расширений, обеспечивающих устойчивую к опечаткам и типобезопасную привязку.

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

Пример можно увидеть здесь. Как видно, код стал компактней, при его написании сложнее ошибиться.

Реализацию можно посмотреть в исходниках проекта на google.code. Там же можно посмотреть и пример привязки к спискам данных.

Syringe UserControl testing container

Это такая утилита для тестирования и отладки элементов управления (UserControl’ов) WindowsForms (возможно, потом и WPF).

Похожа на поставляемый с VS UserControlTestContainer. То есть пользователь может выбрать тип контрола, контрол будет создан на форме и пользователь имеет возможность всячески глумиться над ним, в том числе напрямую редактировать его публичные свойства.

Основное отличие – возможность “подсовывать” контролу его зависимости с помощью механизма Dependency Injection (поэтому проект и называется “шприц” =)). Предусмотрено два способа:

- регистрация зависимости в контейнере для контролов, получающих их через стандартный механизм Component.GetService();

- инъекция зависимостей при конструировании контрола (в конструктор и в свойства).

В результате появится возможность тестировать гораздо более самодостаточные компоненты.

Текущая версия 0.1 (наваянная вчера часа за два =)) почти точно соответствует UserControlTestContainer (если не считать багов =))

Проект живет здесь. Буду рад комментариям.

Все уже написали, один я остался.
Исправляюсь.
Пользовательские впечатления:
- красивенько (и интерфейс, и особенности рендеринга, типа подсветки активного элемента HTML);
- шустренько;
- маловато функциональности для меня (я привык к RSS-агрегатору, почтовому клиенту и детальным настройкам в Опере), но jedem das seine (, например, доволен). Опять же, предполагается, что почту и RSS люди будут юзать гугловские =);
- пока глючно (чего стоит падение от сочетания символов %:);
- не проникся идеей ресайза одних только шрифтов;
- проверка орфографии для русского языка отстойна (или "отстой на", как она сама предложила =))

Технические впечатления:
- Необычен (но достоин уважения) подход по выделению закладок в отдельные процессы-sandbox'ы (хотя от вышеупомянутой баги не защищает ;));
- памяти кушает больше, чем Опера
- напрягает периодический ломёж браузера на гугловские сайты (видимо, с сообщениями о перемещениях пользователя, пока не понял);
- напряг пункт в EULA насчет передачи всего сформированного контента в длинные руки гугла, но говорят, что этот пункт отменен;

Мнение:
Цель создания этой программы, скорее всего, все-таки не создание еще одного FLOSS-браузера, а построение клиентской части гугловской платформы разработки Web-приложений (в особенности, работающих на Google App Engine). Т.о., Chrome конкурирует не с IE/Firefox/Safari/Opera, а с Silverlight/JavaFX/AIR. Об этом говорит наличие встроенного отладчика JavaScript и инспектора HTML, использование Gears, упор на быстродействие движка JS.
Такое вот ИМХО.