PostSharp v3

 

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

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

Начиная с третьей версии, существует 3 набора подписок: community, professional и ultimate. Самая продвинутая стоит сейчас со всеми скидками, с учетом RC версии и раннего заказа 800$. При этом ранее бесплатные тулкиты по INPC и управлению потоками перешли в Ultimate версию, а даже не в Professional. Ранее полная версия стоила 150-200$, что было в целом более-менее адекватно с учетом предоставляемых возможностей. Но сейчас цена, на мой взгляд несколько неадекватна тому, что предлагается за нее.

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

С выходом Roslyn многие вещи из Ultimate пакета стали доступны бесплатно, разве что стоит приложить чуть больше усилий для их реализации. Но написав однажды несколько методов помощников, можно многие вещи делать быстро, так что опять же цена и включение возможностей многих только в Ulitmate версию сомнительны весьма.

Далее, есть проблемы при использовании PostSharp и MEF, которые пока что никак не решаются в RC версии и не думаю, что они будут разрешены позднее. MEF не может в своем контексте загрузить сборки PostSharp и аспекты не распознаются.

Честно сказать, не знаю как дальше советовать использовать PostSharp, разве только для некоторых простых задач вроде комплексного и очень подробного логирования по вызовам методов и некоторые простые ситуации. По идее должно отрабатывать слежение за изменением свойств в классе, так как в Community версии еще не отключили внедрение\реализацию интерфейсов с помощью аспектов.

Professional версия, которая включает все аспекты и подходит для существующих платформ требует от вас раскошелится на 500$, что тоже не вот какая маленькая стоимость, честно сказать. Я наверно мог бы заплатить 200$ за полную версию, но…

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

В общем развитие PostSharp меня несколько разочаровало. Очень печально, что столь многообещающий и интересный продукт пошел по такому пути.

Логика на INotifyProperyChanged

Сложность 200-300

В основном я пишу о практических подходах, конкретных реализациях идей и достаточно редко об общей структуре приложений. Как они строятся, как лучше разрабатывать приложения, какие подходы лучше поддерживаются и так далее. Я думаю, что все согласятся, что нельзя написать единое руководство по тому как надо писать приложение. Если бы такое можно было написать, то такое руководство давно было бы написано людьми гораздо более умными и выдающимися, чем я на текущий момент =) Наверно, если бы такое руководство существовало, то наша профессия была бы не столь востребована и весь рынок разработки захватили китайцы и индусы, так как они более усидчивы и исполнительны. К счастью такого руководства пока что нет, да и вряд ли появится, так что смекалка и нестандартность подходов все еще играет на нашей стороне.

Так как идеальную архитектуру не описать, то попробую хотя бы рассказать как не стоит делать в большинстве ситуаций. Хотя, на мой взгляд, описанный ниже подход вообще нигде нельзя применять.

Я уже не раз писал и говорил насколько мне не нравится явная реализация INPC при реализации MVVM для WPF, но недавнее открытие в проекте коллег не смогло меня оставить равнодушным. Честно сказать, я не представлял, что таким образом можно построить логику приложения, но что есть, то есть. Итак, не будем более затягивать вступление и обратим взор на код.

Подробнее

INPC Framework

Сложность 100

Уже не первый раз я поднимаю тему о INotifyPropretyChaned, так как это постоянно мозолит глаза и заставляет придумывать разные подходы к реализации этого функционала. Постоянно разгораются споры как лучше реализовать интерфейс. Примерно раз в месяц попадается статья на CodeProject о том, как совладать с этим интерфейсом, поэтому я не буду больше разоряться о том, какие плюсы и минусы несет ручная реализация, или же реализация с помощью других средств.

Некоторые библиотеки по реализации интерфейса предлагают в «полезную нагрузку» IoC контроллеры и перехватчики в стиле АОП.

Хотя до недавнего момента я использовал часто Kind Of Magic для решения этой проблемы, я неоднократно сталкивался с тем, что люди в свойства запихивают огромный функционал и этим отрицают целесообразность использования средств в духе Magic. Либо же начинают рассказывать о том, что должен быть полный контроль кода – все надо писать руками.

Относительно давно были анонсы о фремворке от Sharpcrafters, но я как-то пропускал их в силу разных причин и загруженности, но наконец дошли руки и я хочу вам рассказать о PostSharp Domain Toolkit, он же INPC Framework.

Коротко о главном

Распространяется PostSharp Domain Toolkit c помощью NuGet пакета. Установить его можно выполнив команду:

Install-Package PostSharp.Toolkit.Domain

После чего установится как сам тулкит, так и PostSharp. Можно начинать работу.

Самый простой и общий сценарий будет заключатся в добавлении атрибута NotifyPropertyChanged к вашей вьюмодели. Всё. Больше ничего делать не надо. Автоматически «магическим» образом будут обработано подавляющее большинство всех сценариев работы в среднестатистическом приложении.

Подробнее

Ненавистный INotifyPropertyChanged

Да, уже из названия видно мое отношение к интерфейсу INotifyPropertyChanged и к его явной реализации в проекте. Я покрываюсь мурашками, и меня бросает в дрожь только при одном виде такого кода:

Какая растрата места на экране, какая колоссальная неэффективность написания кода, какая хрупкость в работе. Передача строковых переменных не может быть не хрупкой.

А когда таких свойств прописано с десяток и все это обернуто в регион (#region), то взгляд стекленеет, становится безжизненным и мозг отказывается верить в реальность происходящего. Конечно, самое большое зло от такого подхода – потеря времени на написание и на чтение.

Более того, это чистый инфраструктурный код, который не должен попадаться на глаза в логике приложения, только если специально его искать. Реализация INotifyPropertyChanged прямой и явный кандидат на реализацию в рамках аспектного-ориентированного программирования.

К сожалению, при разработке пользовательского интерфейса на WPF такая реализация «в лоб» встречается до сих пор сплошь и рядом. Не далее чем неделю назад вычищал такой код из рабочего проекта. Я бы порадовался за трудолюбие и усидчивость разработчиков пишущих такой код, но я склонен думать, что программист должен быть ленивым. В хорошем смысле. Так что лучше потерять немного времени на настройку и потом быстро-быстро все сделать. Далее я опишу 4 более-менее различных подхода к решению данной проблемы.

Подробнее