Техно-логи » c#

Автоматическая реализация INotifyPropertyChanged на Spring.NET

alik — Sat, 04 Feb 2012 01:34:55 +0000

В статье ранее я писал как сделать автоматическую реализацию INotifyPropertyChanged на основе расширений библиотеки NInject. К сожалению, моя жизнь с этой библиотекой не сложилась, NInject был заменен на Spring.NET. При этом схему автореализации надо было как-то перенести без особенных изменений прикладного кода. Объясню, что именно я сделал.

Для начала нам нужен интерфейс, который будет реализовываться всеми потенциальными автонотифицируемыми классами:

    public interface IAutoNotifyPropertyChanged : INotifyPropertyChanged
    {
        void OnPropertyChanged(string propertyName);
    }

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

    public class ViewModelBase : IAutoNotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        public virtual void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

Кроме этого, нам понадобятся атрибуты, которыми мы будет включать/отключать авто-нотификацию:

    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
    public class NotifyOfChangesAttribute : Attribute
    {
    }
    [AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
    public class DoNotNotifyOfChangesAttribute : Attribute
    {
    }

Теперь пришла очередь Pointcut, которые будет определять setter-ы целевых свойств:

    public class AutoNotifyPointcut : StaticMethodMatcherPointcut
    {
        public override bool Matches(MethodInfo method, Type targetType)
        {
            if (!typeof(IAutoNotifyPropertyChanged).IsAssignableFrom(targetType))
                return false;

            // non-setters ignored
            if (!method.Name.StartsWith("set_"))
                return false;

            object[] attributes = targetType.GetCustomAttributes(typeof(NotifyOfChangesAttribute), true);
            if (attributes.Length > 0)
            {
                object[] disables = method.GetCustomAttributes(typeof (DoNotNotifyOfChangesAttribute), true);
                if (disables.Length > 0)
                    return false;

                return true;
            }

            attributes = method.GetCustomAttributes(typeof (NotifyOfChangesAttribute), true);
            return attributes.Length > 0;
        }
    }

Затем нам нужен advice, в котором и будет происходить вся работа:

    public class AfterPropertySetAdvice : IMethodInterceptor
    {
        private static readonly Logger logger = LogManager.GetCurrentClassLogger();

        public object Invoke(IMethodInvocation invocation)
        {
            object proxy = invocation.Proxy;
            string name = null;

            IAutoNotifyPropertyChanged model = proxy as IAutoNotifyPropertyChanged;
            if (model == null)
            {
                logger.Error("Advice is called on non-IAutoNotifyPropertyChanged class");
            }
            else
            {
                name = invocation.Method.Name;
                if (!name.StartsWith("set_"))
                {
                    logger.Error("Cannot notify on non-setter");
                }
                name = name.Substring(4);
            }

            object rval = invocation.Proceed();

            if (name != null)
            {
                model.OnPropertyChanged(name);
            }

            return rval;
        }
    }

Тут для вящего удобсва отладки используется NLog. Его использование можно вовсе удалить.

Так, классы созданы, надо как-то их применить к объектам. Сразу скажу, что из-за особенностей Spring AOP для оборачивания класса в advice надо, чтобы экземпляр класса создавался Spring-ом. Код подключения выглядит примерно так:



  
  

  
    
    
  

  
    
    
      
        *Model
      
    
    
      
        notifyInterceptor

Можно заметить, что оборачиванию будут подвергнуты объекты, id которых заканчивается на «Model». Анонимные объекты будет проигнорированы.

Кажется, что ограничение по имени какое-то странное. Также кажется, что использование InheritanceBasedAopConfigurer выглядит странно в контексте наличия тега aop:config в Spring.NET. Поясню, почему именно так.

В рамках Spring.NET существует 3 способо создания proxy объектов для вызова advice:

Aggregation based – для объекта-обертки генерируется DynamicProxy со своим интерфейсом. Такой объект нельзя привести к оригинальному типу target объекта. Реальный объект в этом случае будет аггрегирован внутри proxy. Нам не подходит из-за несовместимого интерфейса.
Inheritance based – объект-прокси будет наследником класса target объекта, при этом обернуты будут только virtual методы и свойства оригинала. Оригинальный объект будет аггрегирован внутри proxy. В нашем случае это дает интересный спец-эффект: поскольку события тоже проксируются, то добавление обработчика события на объект-обертку не влияет на оригинальный объект. Значит, если внутри advice вызвать событие, то вызов будет превращен в вызов объекта-оригинала, а не обертки. А на внутреннем объекте обработчиков как небыло так и нет. Значит, тоже не подходит
InheritanceBasedAopConfigurer – новый способ генерации вызовов, добавленный в Spring 1.2. Идея состоит в изменении кода оригинального объекта. Вот это нам подходит, но дает указанные выше ограничения на создание объектов

Пример создания объекта:

Простая реализация INotifyPropertyChanged

alik — Tue, 31 Jan 2012 01:10:34 +0000

При разработке для платформы .NET часто приходится делать так раздражающие всех реализации интерфейса INotifyPropertyChanged на классах-моделях. Типичный пример выглядит так:

class StatisticsRecord: INotifyPropertyChanged
{
    private string name;
    public string Name { get { return name; } set { name = value; NotifyPropertyChanged("Name"); } }	

    private void NotifyPropertyChanged(string name)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(name));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

На мой взгляд, с этим кодом есть 2 проблемы:

Очень много повторений и кода вызванного необходимостью вызвать NotifyPropertyChanged. Увеличивается количество «тупой» работы.
Использование строковой константы Name в качестве аргумента. Рефакторинг может привести к разрушению биндинга к такому свойству.

По счастью разработчики симпатичного фреймворка NInject сделали расширение Ninject.Extensions.Interception, которое позволяет решить описанные выше проблемы за счет использования динамического AOP. Используется это так:

Подключаем к проекту библиотеки NInject, Ninject.Extensions.Interception, Castle.Core, Ninject.Extensions.Interception.DynamicProxy

Создаем класс-реализацию интерфейса IAutoNotifyPropertyChanged, например так:

public class ViewModelBase : IAutoNotifyPropertyChanged
{
     public event PropertyChangedEventHandler PropertyChanged;

     public void OnPropertyChanged(string propertyName)
     {
         PropertyChangedEventHandler handler = PropertyChanged;
         if (handler != null)
         {
             handler(this, new PropertyChangedEventArgs(propertyName));
         }
     }
}

Используем этот класс в нашем классе модели. Например:
```
[NotifyOfChanges]
class StatisticsRecord: INotifyPropertyChanged
{
    public virtual string Name { get; set; }

    [DoNotNotifyOfChanges]
    public virtual string NonNotifyableProperty { get; set; }
}
```
NB! Важно, чтобы getter-ы и setter-ы были виртуальными, поскольку мы используем DynamicProxy для добавления нотификаций
Подключаем «перехватчик» при конфигурации ядра NInject:
```
...
kernel.Components.Add();
...
```

Код стал короче и понятнее напорядок.

PS. Детали того, как именно это все устроено смотрите тут:

System.BadImageFormatException при загрузке тестов в ReSharper

alik — Mon, 23 Jan 2012 22:31:01 +0000

В начале создания авто-тестов в одном проекте на C# начал возникать System.BadImageFormatException при попытке запуска тестов из ReSharper. Выяснение показало, что проблема была в том, что сборка с тестами имела Any CPU. А тестируемые классы были в EXE, который был собран в x86. При этом Windows используется 64х битный, следовательно Any CPU = x64.

Решение просто – указать в тестовой сборке целевую платформу x86. Это делается в закладке Build свойств проекта тестовой сборки.

Названия обработчиков событий в VS2010

alik — Mon, 09 Jan 2012 15:05:36 +0000

После установки ReSharper на Visual Studio 2010 (всем разработчикам на C# рекоммендую, кста) наиболее активно разражает подсвечивание названий методов, который автоматически генерируются Visual Designer для обработки событий, поскольку название типа «Form1_Load» никак не соответствует идеям начинать название с глагола и не использовать «_». Но это можно исправить.

Есть 2 способа исправления проблемы.

1. Изменить способ генерации названий методов
Предпочтительный

Установить плагин EventHandler Naming, который позволяет менять политику именования методов-обработчиков. Устанавливать можно прямо из Extension manager. Даже настройки не требует, по умолчанию настроен как On${SiteName}${EventName}, например, OnForm1Load. Если надо, настраивается.

2. Настроить ReSharper, чтобы он не ругался

Идем в меню ReSharper | Options | Languages | C# | C# Naming Style
Переключаем на «Advanced settings…»
Меняем значение «Event subscriptions on fields» с умолчального $object$_On$event$ на $object$_$event$

VS.NET: интеграция с ANTLR

alik — Wed, 11 Feb 2009 14:19:57 +0000

Для разработки парсеров искусственых языков (ИЯ) часто используются различные инструменты генерации. Один из таких инструментов – ANTLR. Я использовал ANTLR в одном из проектов для разбора 2 специальных ИЯ. Проект делался на C# в среде VS.NET 2008. Среда ANTLRWorks являлась хоть и работающим, но очень неудобным решением.

Недостатки использования ANTLRWorks были в следующем:

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

Качественное решение должно быть избавлено от этих недостатков.

Для работы с грамматиками ANTLR можно использовать плагин nFringe ANTLR. Плагин распространяется бесплатно и легко устанавливается на VS.NET 2008.

Теперь надо добавить в проект возможность автоматической перегенерации грамматики в процессе компиляции проекта через VS.NET. Делаем следующее:

Подготовка окружения:

Убедиться, что на вашем компьютере установлена Java. Достаточно ввести в командной строке «java -version», чтобы это проверить. Если не установлена – установить.
Установить текущую версию инструмента antlr.jar, он будет использоваться для генерации кода. На момент написания заметки текущая стабильная версия – 3.1.1. Версия, которая не требует java, существует, но находится в состоянии beta.
Закрыть проект
Найти файл .csproj, который описывает проект
Открыть его на редактирование (например, через notepad)

Изменение проекта

Вставить следующий текст перед закрывающим тегом Project:

^?View Code XML

  >
     Include="SimpleCalc.g">
      >SimpleCalcLexer.cs;SimpleCalcParser.cs>
    >
     Include="BigCalc.g">
      >BigCalcLexer.cs;BigCalcParser.cs>
    >
  >
   Name="GenerateAntlrCode" Inputs="@(Antlr3)" Outputs="%(Antlr3.OutputFiles)">
     Command="java -cp C:\Libs\ANTLR\antlr-3.1.1.jar org.antlr.Tool -message-format vs2005 @(Antlr3)" Outputs="%(Antlr3.OutputFiles)"/>
  >
  >
    >GenerateAntlrCode;$(BuildDependsOn)>
  >

NB! Нужно заменить названия грамматик и названия выходных файлов, а также правильно указать местоположение файла antlr.jar.

Далее надо добавить зависимости лексера и парсера от грамматики. Находим упоминания файлов SimpleCalcLexer.cs и SimpleCalcParser.cs внутри тега ItemGroup, содержащего упоминания файла AssemblyInfo.cs. Если их нет, значит надо добавить. В результате упоминания этих файлов должны иметь вид:

^?View Code XML

 Include="SimpleCalcLexer.cs">
  >True>
  >True>
  >SimpleCalc.g>
>
 Include="SimpleCalcParser.cs">
  >True>
  >True>
  >SimpleCalc.g>
>

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