gandjustas' blog

Типы, подтипы и вариантность.

noreply@blogger.com (gandjustas) — Sat, 07 Nov 2009 15:24:00 +0000

Скоро (22 марта 2010) выходит Visual Studio 2010, которая будет поддерживать C# 4.0 Больше всего вопросов возникает из-за новой фичи языка – ко- и контр- вариантности. Попытаюсь дать объяснение на человеческом языке.

В любой системе типов существуют отношения между типами. Нас интересует отношение типа-подтип. Для типов A и B будем обозначать A :> B, если A является подтипом B (B является супертипом A). Если A является подтипом B, то везде где в программе требуется значение типа B можно подставлять значение типа A без каких-либо дополнительных конструкций.

Например во многих языках тип целых чисел является подтипом вещественных. В ОО-языках такое отношение реализуется за счет наследования. Если A является наследником B, то A является подтипом B.

Тут стоит вспомнить принцип LSP (принцип подстановки Барбары Лисков). Он ошибочно приписывается к ООП, хотя имеет к нему весьма отдаленное отношение. Принцип гласит что если A :> B, то любое утверждение для B должно быть верно для A. Выполнение этого принципа означает что поведение программы при подстановке значения типа A там где требуется B не изменится.

Но это я ушел в сторону. Когда у нас чистый ООП язык (как smalltalk) тогда отношения типов-подтипов исчерпываются наследованием, которое создает довольно простые отношения. Все становится сложно когда появляются типы, параметризуемые другими типами (обобщенные типы).

Будем обозначать обобщенный типа как T<`a>, где `a – параметр типа. Конкретный тип при подстановке параметра будем обозначать T<A>, где A – какой-то тип. Для иллюстраций нам понадобится обобщенный тип с одним параметром, хотя типов-параметром может быть много.

Тут возникает интересный вопрос. Если A :> B, то как связаны T<A> и T<B> ?

Тип T<`a> называется ковариантными, если для A :> B выполняется T<A> :> T<B>, и контрвариантым, если A :> B выполняется T<B> :> T<A>,
если же T<A> и T<B> не связаны никакими отношениями, то такой тип называет инвариантым.

Примеры.

1)IEnumerable<T>. Например если Apple унаследован от Fruit (то есть Apple :> Fruit), то вполне резонно было бы иметь IEnumerable<Apple> :> IEnumerable<Fruit>. Действительно, в .NET 4 IEnumerable<T> является ковариантым и имеет сигнатуру IEnumerable<out T>.

2)Action<T>. Например есть метод void Eat(Fruit f), он имеет тип Action<Fruit>, и у нас Apple :> Fruit. Тогда было бы хорошо иметь Action<Fuit> :> Action<Apple>, то есть если нам куда-то понадобится передавать Action<Apple> мы могли бы туда передать Action<Fruit>. В .NET 4 Action<T> является конртвариантным и имеет сигнатуру Action<in T>.

Магические слова in и out.

Такие модификаторы были выбраны неслучайно. Ко- и контр- вариантность может приводить к ошибкам при неумелом использовании. Например массивы в .NET 2 и выше являются ковариантными. То есть там где требуется Fruit[] можно передать Apple[]. Но программист может внутри метода, обрабатывающего Fruit[] присвоить элементу массива значение типа Banana. Что приведет к runtime error.

Чтобы ковариантность была безопасной необходимо чтобы ковариантные типы-аргументы были только в выходных значениях методов. То есть для T<out `a> можно писать методы возвращающие `a или имеющие out-параметры типа `a. также могут быть get-only свойства, возвращающие `a.

Аналогично для контрвариантного T<in `a> параметры типа `a могут быть только во входных параметрах методов.

Темная сторона силы.

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

PS. В C# отношение тип-подтип проверяется оператором is.

MVVM и TreeView

noreply@blogger.com (gandjustas) — Tue, 29 Sep 2009 07:08:00 +0000

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

Основной недостаток TreeView в WPF заключается в том что не существует тривиальных путей подружить этот контрол с паттерном MVVM.

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

   1: public class TreeViewItemModel: ViewModelBase

   2: {

   3:     string _name;

4:

   5:     public TreeViewItemModel()

   6:     {

   7:         Children = new ObservableCollection<TreeViewItemModel>();

   8:     }

9:

  10:     public string Name

  11:     {

  12:         get { return _name; }

  13:         set { _name = value; OnPropertyChanged("Name"); }

  14:     }

15:

  16:     public ObservableCollection<TreeViewItemModel> Children { get; private set; }

  17: }

ViewModelBase – класс из MVVM Toolkit.

В XAML пишем простой темплейт

   1: <TreeView.ItemTemplate>

   2:     <HierarchicalDataTemplate ItemsSource="{Binding Children}">

   3:         <TextBlock Text="{Binding Name}" />

   4:     </HierarchicalDataTemplate>

   5: </TreeView.ItemTemplate>

Теперь можно в качестве ItemsSource для TreeView указать любую коллекцию TreeViewItemModel.

Обеспечить обратную связь – от TreeView к модели представления – гораздо сложнее. Свойство TreeView.SelectedValue не имеет сеттера, поэтому привязать его в XAML к модели представления не получится, надо искать обходные пути.

Можно привязать свойство TreeViewItem.IsSelected к модели вида, но делать это надо в стиле дерева, а не в DataTemplate.

   1: <TreeView.ItemContainerStyle>

   2:     <Style TargetType="{x:Type TreeViewItem}">

   3:         <Setter Property="IsSelected" Value="{Binding IsSelected, Mode=TwoWay}" />

   4:     </Style>

   5: </TreeView.ItemContainerStyle>

В класс TreeViewItemModel надо добавить следующее свойство:

   1: bool _isSelected;

2:

   3: public bool IsSelected

   4: {

   5:     get { return _isSelected; }

   6:     set { _isSelected = value; OnPropertyChanged("IsSelected"); }

   7: }

Теперь можно создать модель представления всего дерева:

   1: public class TreeViewModel : ViewModelBase

   2: {

   3:    public TreeViewModel()

   4:    {

   5:        TopLevelItems = new ObservableCollection<TreeViewItemModel>();

   6:    }

7:

   8:    public ObservableCollection<TreeViewItemModel> TopLevelItems { get; private set; }

9:

  10:    public TreeViewItemModel SelectedItem

  11:    {

  12:        get

  13:        {

  14:            return TopLevelItems

  15:                       .Traverse(item => item.Children)

  16:                       .FirstOrDefault(m => m.IsSelected);

  17:        }

  18:    }

  19: }

Изобретение метода Traverse для обхода древообразных структур данных оставлю как домашнее задание.

Теперь в любой момент времени у TreeViewModel можно получить выбранный элемент. Но свойство SelectedItem не поддерживает событие PropertyChanged, поэтому в интерфейсе вы не увидите изменений.

Надо исправить эту досадную ситуацию. Для этого надо подписаться на событие PropertyChanged для всех узлов дерева (в том числе для всех добавляемых) и желательно отписываться при удалении узлов из дерева, при изменении свойства IsSelected узла кидать событие PropertyChanged для свойства SelectedItem.

Полный код TreeViewModel:

   1: public class TreeViewModel : ViewModelBase

   2: {

   3:     PropertyChangedEventHandler _propertyChangedHandler;

   4:     NotifyCollectionChangedEventHandler _collectionChangedhandler;

5:

   6:     public TreeViewModel()

   7:     {

   8:         TopLevelItems = new ObservableCollection<TreeViewItemModel>();

   9:         _propertyChangedHandler = new PropertyChangedEventHandler(item_PropertyChanged);

  10:         _collectionChangedhandler = new NotifyCollectionChangedEventHandler(items_CollectionChanged);

  11:         TopLevelItems.CollectionChanged += _collectionChangedhandler;

  12:     }

13:

  14:     public ObservableCollection<TreeViewItemModel> TopLevelItems { get; private set; }

15:

  16:     public TreeViewItemModel SelectedItem

  17:     {

  18:         get

  19:         {

  20:             return TopLevelItems

  21:                        .Traverse(item => item.Children)

  22:                        .FirstOrDefault(m => m.IsSelected);

  23:         }

  24:     }

25:

  26:     void subscribePropertyChanged(TreeViewItemModel item)

  27:     {

  28:         item.PropertyChanged += _propertyChangedHandler;

  29:         item.Children.CollectionChanged += _collectionChangedhandler;

  30:         foreach (var subitem in item.Children)

  31:         {

  32:             subscribePropertyChanged(subitem);

  33:         }

  34:     }

35:

  36:     void unsubscribePropertyChanged(TreeViewItemModel item)

  37:     {

  38:         foreach (var subitem in item.Children)

  39:         {

  40:             unsubscribePropertyChanged(subitem);

  41:         }

  42:         item.Children.CollectionChanged -= _collectionChangedhandler;

  43:         item.PropertyChanged -= _propertyChangedHandler;

  44:     }

45:

46:

  47:     void items_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)

  48:     {

  49:         if (e.OldItems != null)

  50:         {

  51:             foreach (TreeViewItemModel item in e.OldItems)

  52:             {

  53:                 unsubscribePropertyChanged(item);

  54:             }

  55:         }

56:

  57:         if (e.NewItems != null)

  58:         {

  59:             foreach (TreeViewItemModel item in e.NewItems)

  60:             {

  61:                 subscribePropertyChanged(item);

  62:             }

  63:         }

  64:     }

65:

  66:     void item_PropertyChanged(object sender, PropertyChangedEventArgs e)

  67:     {

  68:         if (e.PropertyName == "IsSelected")

  69:         {

  70:             OnPropertyChanged("SelectedItem");

  71:         }

  72:     }

  73: }

XAML код элемента TreeView:

   1: <TreeView ItemsSource="{Binding TopLevelItems}">

   2:     <TreeView.ItemContainerStyle>

   3:         <Style TargetType="{x:Type TreeViewItem}">

   4:             <Setter Property="IsSelected" Value="{Binding IsSelected, Mode=TwoWay}" />

   5:         </Style>

   6:     </TreeView.ItemContainerStyle>

7:

   8:     <TreeView.ItemTemplate>

   9:         <HierarchicalDataTemplate ItemsSource="{Binding Children}">

  10:             <!--Здесь можно задать любой шаблон для элемента-->

  11:             <TextBlock Text="{Binding Name}" />

  12:         </HierarchicalDataTemplate>

  13:     </TreeView.ItemTemplate>

  14: </TreeView>

PS. TreeViewItem также имеет свойство IsExpanded, которое очень помогает если надо сделать отложенную загрузку элементов дерева.

Паттерн MVVM. Часть 2.

noreply@blogger.com (gandjustas) — Wed, 08 Jul 2009 18:25:00 +0000

В первой части я рассказал про байндинги и команды, которые позволяют вынести из формы всю логику во viewmodel.

На просторах интернета можно найти MVVM Toolkit, в котором есть необходимый код, упрощающий разработку приложений с использованием MVVM.

Кроме байндингов и команд немаловажную роль в MVVM играют шаблоны данных (DataTemplate). Они позволяют задавать шаблоны отображения определенных типов, что заметно упрощает композицию элементов UI.

Наиболее подробно, с примерами, применение шаблонов описано в этой статье.

Паттерн MVVM. Часть 1.

noreply@blogger.com (gandjustas) — Thu, 02 Jul 2009 21:17:00 +0000

MVVM – Model – View – ViewModel – паттерн организации PL (presentation layer – уровень представления).

Паттерн MVVM применяется при создании приложений с помощью WPF и Silverlight. Этот паттерн был придуман архитектором этих самых WPF и Silverlight - John Gossman (его блог). Паттерн MVVM применяется в Expression Blend.

Идеологически MVVM похож на Presentation Model описанный небезызвестным Фаулером, но MVVM сильно опирается на возможности WPF.

Основная особенность MVVM заключается в том, что все поведение выносится из представления (view) в модель представления (view model). Связывание представления и модели представления осуществляется декларативными байндингами в XAML разметке. Это позволяет тестировать все детали интерфейса не используя сложных инструментальных средств.

Я сначала хотел кратко описать применение MVVM и Unity для построения PL, но понял что одного поста для описания возможностей MVVM очень мало.

В WPF для передачи данных между объектами и визуальными элементами используются байндинги (binding – привязка) в простонародии биндинги. Передача может быть как однонаправленная, так и двунаправленная. Работают байндинги с помощью зависимых свойств (DependencyProperty) или интерфейса INotifyPropertyChanged. Передача управляющих воздействий от визуальных элементов осуществляется с помощью команд, реализующих интерфейс ICommand.

Для начала надоевший уже пример SayHello.

Как всегда используется супер-сложный класс бизнес логики:

public interface ISayHelloService
{
    string SayHello(string name);
}
 
public class SayHelloSerivce : ISayHelloService
{
    public string SayHello(string name)
    {
        return "Привет, " + name;
    }
}

Теперь определение класса команды, которая состоит из пары делегатов

public class DelegateCommand : ICommand
{
    Func<object, bool> _canExecute;
    Action<object> _execute;

    //Конструктор
    public DelegateCommand(Func<object, bool> canExecute, Action<object> execute)
    {
        this._canExecute = canExecute;
        this._execute = execute;
    }

    //Проверка доступности команды
    public bool CanExecute(object parameter)
    {
        return this._canExecute(parameter);
    }

    //Выполнение команды
    public void Execute(object parameter)
    {
        this._execute(parameter);
    }

    //Служебное событие
    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested += value; }
    }
}

Теперь напишем нашу модель представления.

public class ViewModel: INotifyPropertyChanged
{
    //Имя
    public string Name { get; set; }

    //Текст приветствия
    public string HelloText { get; set; }

    //Команда
    public ICommand SayHelloCommand
    {
        get
        {
            return _sayHelloCommand;
        }
    }


    ISayHelloService _service;

    ICommand _sayHelloCommand;

    
    //Конструктор
    public ViewModel(ISayHelloService service)
    {
        this._service = service;

        //Создаем команду
        this._sayHelloCommand = new DelegateCommand(
            o => CanExecuteHello(),
            o => ExecuteHello());
    }
        
    private void ExecuteHello()
    {
        this.HelloText = _service.SayHello(this.Name);
        OnPropertyChanged("HelloText");
    }

    private bool CanExecuteHello()
    {
        return !string.IsNullOrEmpty(this.Name);
    }


    //Для поддержка байндинга
    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

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

    #endregion
}

Получилось слегка многословно по причине того, что пример искусственный.

Дело за разметкой:

<StackPanel>
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="75" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <TextBlock Text="Введите имя"/>
        <TextBox Text="{Binding Name}" Grid.Column="1"/>
    </Grid>
    <TextBox Text="{Binding HelloText}"/>
    <Button Content="Сказать привет" Command="{Binding SayHelloCommand}"/>
</StackPanel>

И немного изменим констрктор View:

public Window1(ViewModel model)
{
    InitializeComponent();
    DataContext = model;
}

В App.xaml уберем атрибут StartupUri, и добавим обработчик события Startup, в котором напишем следующий код:

var container = new UnityContainer();
container
    .RegisterType<ViewModel>()
    .RegisterType<ISayHelloService, SayHelloSerivce>();
var window = container.Resolve<Window1>();
window.Show();

Можно нажать F5 и смотреть что получилось.

Теперь воспользуемся фичами WPF.

Изменим код ViewModel.

public class ViewModel : INotifyPropertyChanged
{
    //Имя
    public string Name
    {
        get { return this._name; }
        set
        {
            this._name = value;
            OnPropertyChanged("Name");
            OnPropertyChanged("HelloText");
        }
    }


    //Текст приветствия
    public string HelloText
    {
        get
        {
            return _service.SayHello(this.Name);
        }
    }

    string _name;
    ISayHelloService _service;

    //Конструктор
    public ViewModel(ISayHelloService service)
    {
        this._service = service;
    }

    //Для поддержка байндинга
    #region INotifyPropertyChanged Members
    //Без изменений
    #endregion
}

В разметке View уберем кнопку и поставим Mode=OneWay для байндинга второго текстбокса.

Кроме этого слега изменим App.xml.cs

var container = new UnityContainer();
container
    .RegisterType<ViewModel>(new ContainerControlledLifetimeManager())
    .RegisterType<ISayHelloService, SayHelloSerivce>();
container.Resolve<Window1>().Show();
container.Resolve<Window1>().Show();

Два созданных окна будут разделять одну ViewModel и при вводе имени в одном из окон результат будет отображаться во всех.

Паттерн MVP и Unity

noreply@blogger.com (gandjustas) — Thu, 25 Jun 2009 17:08:00 +0000

MVP – Model View Presenter – паттерн организации PL (presentation layer – уровень представления).

MVP применяется при создании десктопных интерфейсов. Выделяют три комопнента: есть модель – группа классов, которые отдают данные или получают команды, представление – форма обладающая состоянием и некоторым поведением. Презентер создают для отделения бизнес-логики от деталей GUI-фреймворка. В отличие от MVC в MVP представление определяет презентер, а не наоборот.

MVP обычно строится вокруг существующих GUI-фреймворков. На практике существуют две принципиально различные различные реализации паттерна – Supervising Controller и Passive View.
В первом случае логика помещается в обработчики событий button_click, а сами обработчики помещаются в отдельный класс. Для полной изоляции презентера от деталей представления надо писать достаточно много врапперов\адаптеров.
Во втором случае создается пара интерфейсов для общения между представлением и презентером. При совершении какого-либо действия представление напрямую обращается к презентеру, тот выполняет некоторый код и вызывает установку свойств представления. Passive View способствует максимальному перемещению кода в в презентер, что облегчает тестирование.

Создание MVP в WinForms с помощью Unity.

Создаем новое winforms приложение и грохаем оттуда форму.

Для начала определим служебные интерфейсы.

//Маркерный интерфейс представления
public interface IView
{
}

//Интрефейс презентера
public interface IPresenter<T> where T:IView
{
    T View { get; set; }
}

//Базовый класс для презентера
public abstract class BasePresenter<T> :IPresenter<T> where T:IView
{
    public T View { get; set; }
}

Класс “бизнес-логики” будем использовать тот же, что и в предыдущем посте.

public interface ISayHelloService
{
    string SayHello(string name);
}
 
public class SayHelloSerivce : ISayHelloService
{
    public string SayHello(string name)
    {
        return "Привет, " + name;
    }
}

Теперь определим рабочие интерфейсы.

public interface ISayHelloPresenter : IPresenter<ISayHelloView>
{
    void SayHello();
}

public interface ISayHelloView: IView
{
    string GetInputText();
    void SetOutputText(string text);
}

Для перезнтера код будет тривиальный.

public class SayHelloPresenter : BasePresenter<ISayHelloView>, ISayHelloPresenter
{
    ISayHelloService _service;

    public SayHelloPresenter(ISayHelloService service)
    {
        this._service = service;
    }

    public void SayHello()
    {
        this.View.SetOutputText(_service.SayHello(this.View.GetInputText()));
    }
}

Теперь нарисуем простую формочку:

В коде напишем следеющее:

public partial class Form1 : Form, ISayHelloView
{
    ISayHelloPresenter _presenter;

    public Form1(ISayHelloPresenter presenter)
    {
        InitializeComponent();
        _presenter = presenter;
        //Циклическая зависимость
        _presenter.View = this; 
    }

    public string GetInputText()
    {
        return textBox1.Text;
    }

    public void SetOutputText(string text)
    {
        textBox2.Text = text;
    }

    private void button1_Click(object sender, EventArgs e)
    {
        _presenter.SayHello();
    }
}

Циклическая зависимость в Passive View не позволяет с помощью контейнера пропихнуть все зависимости. Поэтому передача презентеру ссылки на представление делается в коде view.

Теперь чтобы увязать это вместе надо создать и сконфигурировать контейнер. Сделаем это прямо в Program.cs.

static void Main()
{
    var container = new UnityContainer();
    container
        .RegisterType<ISayHelloService, SayHelloSerivce>()
        .RegisterType<ISayHelloPresenter, SayHelloPresenter>()
        .RegisterType<ISayHelloView, Form1>()
        ;
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run((Form)container.Resolve<ISayHelloView>());
}

Вот и все.

Unity + ASP.NET MVC

noreply@blogger.com (gandjustas) — Thu, 25 Jun 2009 09:05:00 +0000

Недавно на хабре появилась статья о Unity. В одном из комментов предложили связать ASP.NET MVC и Unity.

А вот есть прикольная задачка уже не для начинающих — связать ASP.NET MVC с Unity. Требований в целом три:

— обеспечить связывание инфраструктуры контроллеров MVC с инъектором
— модульность
— уникальность контейнера в разрезе сессии

Я бы расписал все, но блин, не успеваю вообще ничего, кроме работы. А вам в рамках обучающих методик будет полезно, имхо.

хабраюзер acerv

Я напишу серию постов о применении Unity в паттернах уровня представления.

Сначала о том что такое MVC.

MVC – Model View Controller – паттерн организации PL (presentation layer – уровень представления). Целью этого паттерна, как и многих других, служит отделение модели (логики работы программы) от представления (средств отображения информации). В итоге применение такого паттерна должно приводить к улучшению тестируемости кода.

В современном виде MVC применяется в вебе. Выглядит так: есть модель – группа классов, которые отдают данные или получают команды, есть различные представления этих данных – HTML, сделанные с помощью какого-либо шаблонизатора, JSON, SOAP, XML или еще какой – либо. Для того чтобы передавать данные от модели к представления вводят контроллер.

Все MVC фреймворки проектируются так, чтобы управление приходило сразу на контроллер. Контроллер вызывает методы модели, если нужно формирует данные для передачи представлению (эти данные называют Presentation Entity, но термин неустоявшийся), и выбирает представление для этих данных.

ASP.NET MVC – фреймворк для ASP.NET, реализующий паттерн MVC.
Контроллеры в ASP.NET MVC – классы, унаследованные от класса Controller, содержащие несколько методов - “действий” (actions). По умолчанию действия отображаются на различные urlы см помощью механизма раутинга (System.Web.Routing).
Каждое действие возвращает ActionResult, который может вызывать генерацию HTML, сериализацию данных в JSON итд. Можно писать свои ActionResult.

Применение Unity в ASP.NET MVC.

Инфраструктура ASP.NET MVC получает имя контроллера из параметров запроса, формируемых механизмом раутинга, потом вызывает класс ControllerFactory, который по имени возвращает экземпляр контроллера.

Сначала создадим новое asp.net mvc приложение. Оно уже включает в себя большой функционал, его трогать не будем.

Чтобы подключить Unity к механизму создания контроллеров надо написать свой класс ControllerFactory. По умолчанию используется DefaultControllerFactory, нам надо изменить в нем один метод, который создает объект контроллера.

public class UnityControllerFactory: DefaultControllerFactory
{
    IUnityContainer _container;

    public UnityControllerFactory(IUnityContainer container)
    {
        this._container = container;
    }

    protected override IController GetControllerInstance(Type controllerType)
    {
        if (controllerType == null)
        {
            return null;
        }

        return (IController)_container.Resolve(controllerType);
    }
}

Теперь в Global.asax добавим следующий код.

protected void Application_Start()
{
    var container = new UnityContainer();
    RegisterControllerFactory(container);
    //...
}

private static void RegisterControllerFactory(IUnityContainer container)
{
    var factory = new UnityControllerFactory(container);
    ControllerBuilder.Current.SetControllerFactory(factory);
}

Жмем F5 и все работает! В принципе для успешного применения unity в asp.net mvc этого достаточно.

Собственно инъекция зависимостей.

Буду использовать один класс “бизнес-логики” во всех примерах.

public interface ISayHelloService
{
    string SayHello(string name);
}

public class SayHelloSerivce : ISayHelloService
{
    public string SayHello(string name)
    {
        return "Привет, " + name;
    }
}

Надеюсь комментарии не нужны.

Снова дополним global.asax.

protected void Application_Start()
{
    var container = new UnityContainer();
    RegisterTypes(container);
    RegisterControllerFactory(container);
    //...
}

private static void RegisterTypes(IUnityContainer container)
{
    container
        .RegisterType<ISayHelloService, SayHelloService>();
}

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

public class SayHelloController : Controller
{
    ISayHelloService _service;

    public SayHelloController(ISayHelloService service)
    {
        this._service = service;
    }

    [AcceptVerbs(HttpVerbs.Get)]
    public ActionResult Index()
    {
        return View();
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Index(string name)
    {
	//Преобразование к object нужно чтобы строка 
	//не была принята за имя View
        return View((object)_service.SayHello(name));
    }
}

Создаем View с типом string, и помещаем в MainContent незамысловатый код:

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
<%using (Html.BeginForm()){%>
    Введите имя <%=Html.TextBox("name")%>
    <br />      
    <input type="submit" value="Сказать привет" />
<%} %>

<%if (!string.IsNullOrEmpty(Model)){%>    
    <h3><%=Html.Encode(Model)%></h3>      
<%} %>
</asp:Content>

Теперь жмем F5, переходим о адресу http://localhost:<порт>/SayHello и смотрим как работает.

MEF

noreply@blogger.com (gandjustas) — Wed, 24 Jun 2009 22:09:00 +0000

MEF – Managed Extensibility Framework – новая библиотека для создания композитных приложений. То есть приложений, которые собираются из отдельных частей.

Скачать его можно по адресу http://mef.codeplex.com/, версия на момент написания поста – Preview 5. На базе MEF построена Visual Studio 2010.

MEF по функциональности похожа на IoC-контейнеры, но авторы не стремились повторить функциональность существующих контейнеров. В MEF есть несколько уникальных фич, которых нету в IoC-контейнерах.

Сразу примеры, снова поиск фильмов. Возьмем основной код из поста про Unity.

// Фильм
public class Movie
{
    public string Title { get; set; }
    public string Director { get; set; }
    public int Year { get; set; }
}

/// <summary>
/// Интерфейс репозитария
/// </summary>
public interface IMovieRepository
{
    IQueryable<Movie> GetMovies();
}

// Сервис поиска фильмов
[Export]
public class MovieFinder
{
    IMovieRepository _repository;

    [ImportingConstructor]
    public MovieFinder(IMovieRepository repository)
    {
        _repository = repository;
    }

    public IEnumerable<Movie> FindByTitle(string q)
    {
        return _repository
                .GetMovies()
                .Where(m => m.Title.Contains(q));
    }
}

// Заглушка для репозитария
[Export(typeof(IMovieRepository))]
public class InMemoryMovieRepository : IMovieRepository
{
    public IQueryable<Movie> GetMovies()
    {
        return new[]   
        {   
            new Movie   
            {   
                Title = "Гарри Поттер и узник Азкабана",   
                Director = "Альфонсо Куарон",   
                Year = 2004   
            },   
            new Movie   
            {   
                Title = "Звездные войны: Эпизод 2 - Атака клонов",   
                Director = "Джордж Лукас",   
                Year = 2002   
            },   
            new Movie   
            {   
                Title = "Властелин колец: Братство кольца",   
                Director = "Питер Джексон",   
                Year = 2001   
            },   
        }.AsQueryable();
    }
}

В коде атрибутами размечены экспортируемые классы и импортирующий конструктор.

Теперь код, который это все использует.

static void Main(string[] args)
{
    //Создание каталога "частей"
    var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());

    //Создание контейнера
    var container = new CompositionContainer(catalog);

    //Получение экземпляра
    var finder = container.GetExportedObject<MovieFinder>();
}

В текущем виде мало отличается от примера с Unity.

На самом деле в MEF гораздо более широкие возможности работы с импортами и экспортами. Экспортировать можно не только классы, но и методы, и значения свойств. Импортировать можно не только через конструктор, но и через свойства и даже через приватные поля (но это не будет работать в частично доверенном окружении).

Упростим пример, класс Movie и Main останутся без изменений.

[Export]
public class MovieFinder
{
    [Import]
    Func<IQueryable<Movie>> _getMovies = null;

    public IEnumerable<Movie> FindByTitle(string q)
    {
        return _getMovies().Where(m => m.Title.Contains(q));
    }
}

public class InMemoryMovieRepository
{
    [Export(typeof(Func<IQueryable<Movie>>))]
    public IQueryable<Movie> GetMovies()
    {
        return new[]   
        {   
            //...
        }.AsQueryable();
    }
}

Также важной фичей MEF является возможность поиска частей в сборках в каталоге на диске, а также мониторинг изменений этих сборок и перезагрузка частей. Кроме того есть API для пересборки частей при изменении.

Но об этом в другой раз.

Нельзя построить коммунизм на ESB

noreply@blogger.com (gandjustas) — Mon, 11 May 2009 11:37:00 +0000

SOA с помощью IoC – это практически коммунизм. В точности как гласит лозунг “от каждого по возможностям, каждому - по потребностям”. Потребности – зависимости классов, возможности – реализуемые интерфейсы, а ЦК КПСС – IoC-контейнер.

В архитектуре с шиной сообщений (ESB) сервисы не общаются друг с другом, а только с шиной, живут в изоляции. Это не коммунизм, а тирания.

Плачь по SOA

noreply@blogger.com (gandjustas) — Fri, 08 May 2009 20:46:00 +0000

Наверное все слышали о SOA, но у большинства эти три буквы ассоциируются исключительно с ws-* вебсервисами. Хотя на самом деле это очень хорошая концепция построения программной системы из компонент, абсолютно не привязанная к способам реализации взаимодействия.

Принцип SOA состоит в следующем. Вся система разбивается на слабо связные компоненты – сервисы. Сервисы знают друг о друге только контракт. Сервисы в SOA, в отличие от объектов в ООП, не обладают свойством идентичности. Так как сервисы не знают ничего друг о друге, то должен быть общеизвестный сервис, который по контракту может выдать ссылку на сервис.

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

В мире ws-* вебсервисов контракты реализуются с помощью WSDL, а общеизвестными сервисами являются брокеры, которые по WSDL могут возвращать ссылки на сервисы. Сейчас наблюдается практически полное отсутствие ws-брокеров на просторах интернета. WSDL не описывает семантику, а только синтаксис, поэтому просто получить ссылку на сервис не получится, неизвестно вообще говоря что этот сервис делает. Кроме того нету стандартных контрактов, каждый вендор делает такой контракт как захочется. Это все приводит к тому что идея брокеров на практике оказывается нежизнеспособной. В большинстве библиотек вебсервисов не реализована поддержка UDDI – протокола общения с брокерами. Глобального коммунизма не будет.

А вот в отдельно взятой ~~стране~~ программе такой коммунизм построить можно. Роль контрактов будут играть интерфейсы языка, роль сервисов – объекты, реализующие интерфейсы, а в качестве брокера будет выступать IoC-контейнер. Он как раз умеет по интерфейсу отдавать ссылку на сервис, а его возможность собирать зависимости позволит избавить сами сервисы от общения с брокером.

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

Ортогональность

noreply@blogger.com (gandjustas) — Wed, 18 Mar 2009 23:30:00 +0000

Навеяно холиварами на RSDN…

Если вы читали книгу «Программист-прагматик» Эндрю Ханта и Дэйва Томаса, то наверное знаете о чем пойдет речь.

Ортогональность также называют Separation of Concerns или применением принципа “Разделяй и властвуй” в архитектуре программ, принцип SRP является отражением идеи ортогональности.

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

Об ортогональности мало пишут в книжках и умных статьях по архитектуре. Обычно пишут о паттернах, доменной модели, базах данных и об Ubiquitous Language (боюсь даже переводить). При этом ортогональность является основополагающим принципом разработки ПО.

Вы сами часто сталкивались с ортогональностью в разных проявлениях: разделение модели и представления, отделение Data Access Layer от Business Logic Layer, разделение данных и алгоритмов их обработки в паттернах State, Strategy.

Идея ортогональности в архитектуре программ очень проста – разделять на независимые части все что только можно разделить. Если какая-то задача может быть решена независимо от других, то в решении этой задачи не должно появляться лишних связей любой природы с другими частями программы.

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

Использование IoC-контейнеров делает управление зависимостями и временем жизни объектов независимым от пользователей этих объектов. AOP ортогонализирует (ух какое слово) так называемую сквозную функциональность. Методу, результат которого кешируется, и вызывающему его коду абсолютно не надо знать что происходит кеширование и как оно происходит. Применение паттернов MVC, MVP, MVVM делает независимыми сам интерфейс, от логики работы с низлежащей моделью, и даже если модель переедет на другую машину в сети, то интерфейс править не придется. Это все примеры ортогональности.

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

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

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

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

Доменная модель или почему Фаулер неправ.

Domain Model – очень популярный паттерн построения бизнес-логики в бизнес-приложении. Заключается как раз в объединении данных, хранимых чаще всего в БД, и методов бизнес-логики в одном объекте. Все это преподносится как соответствие модели предметной области из реального мира.

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

Во-первых не все методы бизнес-логики удается распихать по доменным объектам, приходится создавать искусственные объекты – контейнеры методов, что уменьшает согласованность и ухудшает читаемость.

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

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

Заключение

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

Применение Enterprise Library

noreply@blogger.com (gandjustas) — Tue, 17 Mar 2009 21:59:00 +0000

Все возможности Enterprise Library можно применять по-отдельности и радоваться жизни. Но если бы это была единственная возможность я бы не написал этот пост.

Магия начинается в сборке Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.
В этой сборке в одноименном неймспейсе содержатся call handlerы и атрибуты для навешивания обработчиков на методы. Как использовать call handlerы я рассказывал в этом посте.

Кратко опишу доступные хендлеры:

AuthorizationCallHandler – задействует Security Application Block для авторизации при вызове перехваченного метода
CachingCallHandler – обработчик, кеширующий результаты вызова перехваченного метода средствами Caching Application Block. Может быть чрезвычайно полезным для веб-разработки.
ExceptionCallHandler – позволяет декларативно задавать стратегию обработки исключений в перехваченном методе. Стратегии задаются средствами Exception Handling Application Block.
LogCallHandler – задействует Logging Application Block для логгирования вызова перехваченного метода.
ValidationCallHandler – вызывает валидацию параметров метода. Параметры валидации должны быть заданы атрибутами или в конфигурации Validation Application Block.
PerformanceCounterCallHandler – обработчик, который занимается сбором информации о параметрах быстродействия перехваченного метода. Информация сохраняется в PreformanceCounterах. В самой сборке Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers есть Installer (который можно запустить через installutil), создающий необходимые счетчики производительности.

Если интересует только runtime AOP, то можно использовать не полновесный IoC-контейнер Unity, а легковесный генератор прокси-классов из Policy Injection Application Block.

Кроме перехватчиков вызовов существует другой способ интеграции всех application blocks с контейнером Uinty. Практический каждый application block из состава enterprise library содержит класс – расширение Unity, которое контейнер возвращать объекты-фасады при запросе определенных типов.

Все расширения можно найти в основной сборке application block, в неймспейсе Configuration.Unity. Классы расширений называются ИмяБлокаExtension.

Для Logging Application Block расширение заставляет Unity возвращать фасад логгера по запросу типа LogWriter.
Для Exception Handling Application Block основной тип фасада – ExceptionManager.
Для Caching Application Block контейнер возвращает реализации интерфейсов ICacheManager, IStorageEncryptionProvider, IBackingStore.
Для Security Application Block контейнер возвращает реализации интерфейсов IAuthorizationProvider, ISecurityCacheProvider.
Для Data Access Application Block контейнер возвращает экземпляры класса Database, аналогично DatabaseFactory.CreateDatabase. Можно получать как экземпляр по-умолчанию, так и именованный экземпляр.
Для Cryptography Application Block (который находится в сборке Microsoft.Practices.EnterpriseLibrary.Security.Cryptography) расширение заставляет Unity возвращать фасад по запросу типа CryptographyManager, а также реализации интерфейсов IHashProvider и ISymmetricCryptoProvider.

При использовании application blocks совместно с unity все настройки блоков надо задавать в файле конфигурации. Для этого в Enterpise Library есть удобная утилита.

К сожалению я не смог придумать адекватного примера, который сможет показать хотя бы малую часть возможностей Enterprise Library с использованием Unity.

Баг в Entity Framework

noreply@blogger.com (gandjustas) — Tue, 10 Feb 2009 13:13:00 +0000

Обнаружил очень неприятный баг с Entity Framework.
ObjectContext грузит метаданные не при конструировании, а при первом обращении к методам загрузки данных. При этом вызывается this.MetadataWorkspace.LoadAssemblyForType((тип), Assembly.GetCallingAssembly());
Если вызывающая сборка (Assembly.GetCallingAssembly()) не содержит прямой или косвенной ссылки на сборку с метаданными, то загружены они не будут и любой метод чтения отвалится с непонятной ошибкой.

Я наткнулся на такую ситуацию когда вынес extension-метод для ObjecxtContext в отдельную сборку, которая не имела ссылки на сборку с моделью. Сам extension-метод вызывался для только что созданного контекста.

Workaround для этого такой: для только что созданного контекста вызвать context.MetadataWorkspace.LoadFromAssembly(context.GetType().Assembly);

Введение в Enterpise Library

noreply@blogger.com (gandjustas) — Fri, 30 Jan 2009 19:35:00 +0000

Enterprise Library – библиотека от группы patterns & practicies Microsoft. Проект живет по адресу http://www.codeplex.com/entlib.

Enterprise Library состоит из набора компонент, называемых application blocks, каждый из которых решает определенную задачу, часто возникающую при разработке ПО.

В состав Enterprise Library входят следующие блоки:

Unity Application Block - IoC-контейнер Unity
Policy Injection Application Block – AOP времени выполнения
Validation Application Block – небольшой фреймворк для валидации
Logging Application Block – логгер
Exception Handling Application Block – фреймворк для создания политик обработки исключений в приложении
Caching Application Block – фреймворк для кеширования
Security Application Block – библиотека для авторизации, практически повторение ASP.NET Membership
Data Access Application Block – библиотека, упрощающая работу с ADO.NET, используется другими блоками
Cryptography Application Block – библиотека для упрощения работы с криптографическими функциями в .NET

Все эти блоки могут настраиваться через config-файл, для этого в составе Enterprise Library есть утилита упрощающая этот процесс.

Почти все блоки можно использовать по-отдельности, но основная сила Enterprise Library состоит в том, что все блоки можно подключить через Unity.

Фабрики объектов в Unity

noreply@blogger.com (gandjustas) — Mon, 26 Jan 2009 11:50:00 +0000

В этом посте я описал как с помощью LifetimeManager можно научить Unity использовать фабрику для создания объектов.

На самом деле так делать не стоит. В составе Unity есть сборка Microsoft.Practices.Unity.StaticFactory.dll в которой находится расширение контейнера для использования фабрики объектов.

Регистрация фабрики происходит методом RegisterFactory, который принимает делегат FactoryDelegate. Этот делегат принимает параметром IUnityContainer, и возвращает object.

Пример

var r = new Random();
var container = new UnityContainer();
container
    .AddNewExtension<StaticFactoryExtension>()
    .Configure<StaticFactoryExtension>()
        .RegisterFactory<int>("random", c => r.Next());

Чтобы этим всем было удобнее пользоваться можно написать extension-методы

public static class UnityStaticFactoryExtensions
{
    private static IStaticFactoryConfiguration GetExtension(IUnityContainer container)
    {
        var ext = container.Configure<StaticFactoryExtension>();
        if (ext == null)
        {
            container.AddNewExtension<StaticFactoryExtension>();
            ext = container.Configure<StaticFactoryExtension>();
        }
        return ext;
    }

    public static IUnityContainer RegisterFactory<T>(
        this IUnityContainer container, 
        Func<IUnityContainer, T> factoryMethod)
    {
        GetExtension(container).RegisterFactory<T>(c => factoryMethod(c));
        return container;
    }

    public static IUnityContainer RegisterFactory<T>(
        this IUnityContainer container, 
        string name, 
        Func<IUnityContainer, T> factoryMethod)
    {
        GetExtension(container).RegisterFactory<T>(name, c => factoryMethod(c));
        return container;
    }
}

Тогда код примера, показанного выше можно записать гораздо короче

var r = new Random();
var container = new UnityContainer();
container.RegisterFactory("random", c => r.Next());

AOP времени исполнения в Unity

noreply@blogger.com (gandjustas) — Sat, 24 Jan 2009 22:02:00 +0000

Для тех кто не знает – AOP это Aspect-Oriented Programming, Аспектно-ориентированное программирование.

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

Концепция AOP заключается в том что сквозная функциональность выделяется в отдельные сущности , называемые аспектами, и декларативно задается использование аспектов в коде.

AOP для .NET может быть реализован двумя способами: изменение кода при компиляции инструментами типа PostSharp или макросами языка Nemerle, или перехват вызовов на стадии выполнения.

В составе Unity есть сборка Microsoft.Practices.Unity.Interception, которая содержит расширение контейнера Unity для перехвата вызовов объектов собираемых контейнером.

Чтобы перехватывать вызовы надо контейнеру сообщить что перехватывать, как перехватывать, и зачем перехватывать.
Что перехватывать задается политиками (Policy), как перехватывать определяют перехватчики (Interceptor), зачем перехватывать определяют обработчики вызовов (CallHandlers).
Эти три части механизма перехвата не зависят друг от друга.

Перехватчики – это классы, реализующие интерфейс IInterceptor. В библиотеке есть классы InterfaceInterceptor для перехвата методов интерфейса, VirtualMethodInterceptor – для перехвата виртуальных методов класса, TransparentProxyInterceptor – для перехвата с помощью прокси-классов, используемых для .NET Remoting.

Обработчики вызовов – это классы, которые реализуют интерфейс ICallHandler, в котором только один нужный метод – Invoke.

Политики бывают двух видов – управляемая атрибутами (AttributeDrivenPolicy) и управляемая правилами (RuleDrivenPolicy).
По-умолчанию используется AttributeDrivenPolicy, которая заключается в том что обработчики вызовов задаются атрибутами, унаследованными от HandlerAttribute, и перехватываются только те методы, для которых заданы эти атрибуты (или атрибуты заданы для классов).
RuleDrivenPolicy позволяет задавать какие методы будут перехватываться с помощью набора правил (IMatchingRule) и какие обработчики будут при этом вызываться.

Подробнее по этой ссылке http://msdn.microsoft.com/en-us/library/dd140045.aspx

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

Пример

Сначала создадим обработчик, который просто выводит Hello, world на консоль

public sealed class HelloWorldAttribute : HandlerAttribute
{
    public override ICallHandler CreateHandler(IUnityContainer container)
    {
        return new HelloWorldCallHandler();
    }
}

public class HelloWorldCallHandler: ICallHandler
{
    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
        Console.WriteLine("Hello, world");
        return getNext()(input, getNext);
    }

    public int Order { get; set; }
}

Теперь создадим класс, унаследованный от MarshalByRefObject, чтобы его можно было перехватывать с помощью TransparentProxyInterceptor. Атрибут HelloWorld объявлен выше.

[HelloWorld]
public class SomeService1: MarshalByRefObject
{
    public void Method1()
    {
        Console.WriteLine("SomeService1.Method1");
    }
}

В Main напишем код

container
    .AddNewExtension<Interception>()
    .Configure<Interception>()
        .SetDefaultInterceptorFor<SomeService1>(new TransparentProxyInterceptor());

var s = container.Resolve<SomeService1>();
s.Method1();
Console.ReadLine();

При выполнении будет выведено

Hello, world
SomeService1.Method1

Предположим что SomeService1 нам недоступен и уберем атрибут HelloWorld. Чтобы получить такую же функциональность программы надо дописать несколько строк кода

container
    .AddNewExtension<Interception>()
    .Configure<Interception>()
        .SetDefaultInterceptorFor<SomeService1>(new TransparentProxyInterceptor())
            .AddPolicy("Policy")
                .AddMatchingRule(new TypeMatchingRule(typeof(SomeService1)))
                .AddCallHandler<HelloWorldCallHandler>();

var s = container.Resolve<SomeService1>();
s.Method1();
Console.ReadLine();

Аналогичные настройки можно задать в конфигурационном файле.

Что делать если Unity-контейнер надо передавать как зависимость в другие компоненты?

noreply@blogger.com (gandjustas) — Sat, 24 Jan 2009 11:29:00 +0000

Правильный ответ – ничего.

var container = new UnityContainer();
var resolvedContainer = container.Resolve<IUnityContainer>();

При выполнении такого кода resolvedContainer получит ссылку на сам контейнер. Это значит что если в любом, собираемом из контейнера, классе есть зависимость типа IUnityContainer, то она автоматически будет получать ссылку на контейнер.

Конфигурация Unity

noreply@blogger.com (gandjustas) — Thu, 22 Jan 2009 10:14:00 +0000

Существует четыре различных способа конфигурирования контейнера.

1)Использование соглашений. Фактически отсутствие явного конфигурирования. В Unity используется очень простое соглашение, что в классе должен быть один конструктор, который принимает все зависимости параметрами.
Такой способ подходит для 90% случаев если вы пишите код сами.

2)Указание зависимостей с помощью атрибутов. Для свойств есть DependencyAttribute, для конструктора указывается InjectionConstructorAttribute, для метода InjectionMethodAttribute. Для параметров конструктора и injection-методов также можно указывать DependencyAttribute.
При навешивании DependencyAttribute на свойство или параметр можно указать имя зависимости.

3)Задание конфигурации в коде при добавлении элемента в контейнер.
Последним параметром метода RegisterType является массив InjectionMember. В этом массиве можно передать объекты типа InjectionProperty, InjectionConstructor и InjectionMethod чтобы указать с помощью каких членов класса проводить инъекцию.
При указании InjectionConstructor и InjectionMethod для каждого параметра можно указать конкретное значение или попросить контейнер резолвить нужный параметр.
Такой способ дает гораздо более многословен, чем все остальные способы, но дает гораздо большую гибкость. С помощью конфигурации в коде можно использовать IoC с классами, к исходникам которых нет доступа.

4)Задание конфигурации в XML. Этот способ имеет смысл применять только если нужно изменять конфигурацию без перекомпиляции программы. Конфигурация в XML не позволяет описывать произвольные типы, поэтому обладает меньшей мощностью по сравнению с конфигурацией в коде.

Подробнее о возможностях конфигурирования Unity можно почитать по ссылкам
http://msdn.microsoft.com/en-us/library/dd203225.aspx
http://msdn.microsoft.com/en-us/library/dd203208.aspx
http://msdn.microsoft.com/en-us/library/dd203195.aspx
http://msdn.microsoft.com/en-us/library/dd203156.aspx
http://msdn.microsoft.com/en-us/library/dd203230.aspx

Overconfiguration или Темная сторона силы

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

Поэтому при использовании любой технологии, которая может очень сильно конфигурироваться, предпочитайте пользоваться соглашениями (Convetions over Configuration) и размещайте конфигурацию как можно ближе к месту использования. Для этого используйте атрибуты и помещайте код конфигурирования в ту же сборку, где находятся конфигурируемые классы.

Управление временем жизни объектов в Unity

noreply@blogger.com (gandjustas) — Thu, 22 Jan 2009 06:39:00 +0000

При регистрации класса или объекта в контейнере можно указать объект LifetimeManager, который будет управлять временем жизни экземпляров в контейнере.

Класс LifetimeManager очень простой, в нем всего три метода GetValue, SetValue и RemoveValue, причем последний не используется.
При помещении объекта в контейнер вызывается метод SetValue, а при необходимости получить объект вызывается GetValue и если он вернул null, то создается новый объект.

В библиотеку Microsoft.Practices.Unity входит несколько менеджеров.

TransientLifetimeManager – ничего не сохраняет, GetValue всегда возвращает null, поэтому объект создается каждый раз. Этот менеджер используется по-умолчанию при вызове RegisterType.

ContainerControlledLifetimeManager – сохраняет объект в локальной переменной. Поэтому объект живет столько же, сколько и контейнер. Этот (вернее другой, но с таким же поведением) менеджер используется по-умолчанию при вызове RegisterInstance.

ExternallyControlledLifetimeManager – сохраняет слабую ссылку (WeakReference) на объект. При использовании этого менеджера и вызове RegisterInstance сам вызывающий код должен управлять временем жизни объекта, помещенного в контейнер. Когда используется RegisterType этот менеджер будет выдавать уже существующий экземпляр объекта если он есть.

PerThreadLifetimeManager – сохраняет объекты в ThreadStatic словаре. Таким образом каждый поток в программе будет использовать свой набор объектов.

Для применения Unity в ASP.NET приложениях очень легко реализовать LifetimeManager, который сохраняет объект в контексте или в сессии.

Другие области применения LifetimeManager

В Unity нет возможности регистрации метода создания объектов, но это очень легко исправить с помощью своего LifetimeManager и пары extension-методов.

public class FactoryLifetimeManager<T>: LifetimeManager
{
    Func<T> _factoryMethod;
    LifetimeManager _baseManager;

    public FactoryLifetimeManager(Func<T> factoryMethod, LifetimeManager baseManager)
    {
        _factoryMethod = factoryMethod;
        _baseManager = baseManager;
    }

    public override object GetValue()
    {
        var obj = _baseManager.GetValue();
        if (obj == null)
        {
            obj = _factoryMethod();
            SetValue(obj);
        }
        return obj;
    }

    public override void RemoveValue()
    {
        _baseManager.RemoveValue();
    }

    public override void SetValue(object newValue)
    {
        _baseManager.SetValue(newValue);
    }
}

public static class UnityFactoryMethodExtensions
{

    public static IUnityContainer RegisterFactory<T>(this IUnityContainer container, Func<T> factoryMethod)
    {
        return container.RegisterFactory<T>(factoryMethod, new TransientLifetimeManager());
    }
    
    public static IUnityContainer RegisterFactory<T>(this IUnityContainer container, Func<T> factoryMethod, LifetimeManager lifetimeManager)
    {
        return container.RegisterType<T>(new FactoryLifetimeManager<T>(factoryMethod, lifetimeManager));
    }

    public static IUnityContainer RegisterFactory<T>(this IUnityContainer container, Func<T> factoryMethod, string name)
    {
        return container.RegisterFactory<T>(factoryMethod, name, new TransientLifetimeManager());
    }
    
    public static IUnityContainer RegisterFactory<T>(this IUnityContainer container, Func<T> factoryMethod, string name, LifetimeManager lifetimeManager)
    {
        return container.RegisterType<T>(name, new FactoryLifetimeManager<T>(factoryMethod, lifetimeManager));
    }
}

Инъекция массивов в Unity

noreply@blogger.com (gandjustas) — Wed, 21 Jan 2009 22:16:00 +0000

Unity умеет резолвить зависимости-массивы. Для такой зависимости контейнер возвращает объекты всех подходящих типов. Даже при разрешении зависимостей с указанием имени будут возвращены все подходящие типы.

Также этого Unity поддерживает разрешение обобщенных массивов.

Пример

Интерфейс и классы логгеров

public interface ILogger
{
    void Write(string message);
}

public class TraceLogger: ILogger
{
    public void Write(string message)
    {
        Trace.Write(message);
    }
}

public class ConsoleLogger: ILogger
{
    public void Write(string message)
    {
        Console.WriteLine(message);
    }
}

Сервис, принимающий обобщенный массив

public class SomeService2<T>
{
    public SomeService2(T[] array)
    {

    }
}

Код, получающий нужный экземпляр

var container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>("ConsoleLogger")
    .RegisterType<ILogger, TraceLogger>("TraceLogger");

var service = container.Resolve<SomeService2<ILogger>>();

При вызове такого кода в конструктор SomeService2 будет передан массив из двух логгеров.

Использование generic-ов в Unity

noreply@blogger.com (gandjustas) — Wed, 21 Jan 2009 14:57:00 +0000

Unity поддерживает работу с generic-типами.
Можно в контейнер поместить обобщенный тип, а потом запросить тип с конкретными параметрами. Подробнее описано по ссылке http://msdn.microsoft.com/en-us/library/dd203156.aspx

Пример кода, использующего такую фичу.

Рассмотрим обобщенный класс репозитария для работы с данными

public interface IRepository<T>
{
    IQueryable<T> Items();
    void Save(T item);
    void Delete(T item);
}

Реализация этого интерфейса для Entity Framework

public class EFRepository<T> : IRepository<T> where T : EntityObject
{
    ObjectContext _context;
    string _entitySetName;

    public EFRepository(ObjectContext context)
    {
        _context = context;
        var container = _context
            .MetadataWorkspace
            .GetEntityContainer(
                _context.DefaultContainerName, 
                DataSpace.CSpace);
        var edmEntityType = (EdmEntityTypeAttribute)typeof(T)
            .GetCustomAttributes(
                typeof(EdmEntityTypeAttribute), 
                false)
            .Single();

        _entitySetName = container.BaseEntitySets
            .Single(s => s.ElementType.Name == edmEntityType.Name
                && 
                s.ElementType.NamespaceName == edmEntityType.NamespaceName)
            .Name;
    }

    public IQueryable<T> Items()
    {
        return _context.CreateQuery<T>(_entitySetName);
    }

    public void Save(T item)
    {
        switch (item.EntityState)
        {
            case System.Data.EntityState.Detached:
                _context.AddObject(_entitySetName, item);
                goto case System.Data.EntityState.Added;

            case System.Data.EntityState.Added:
            case System.Data.EntityState.Modified:
                _context.SaveChanges();
                break;
            default:
                break;
        }
    }

    public void Delete(T item)
    {
        _context.DeleteObject(item);
        _context.SaveChanges();
    }
}

Есть EF модель с типом контекста AddressBookEntities и двумя сущностями Person и PhoneNumber и сервис SomeService1, работающий с этими сущностями.
Конструктор сервиса выглядит так:

public SomeService1(IRepository<Person> personsRepository, 
                    IRepository<PhoneNumber> phoneNumbersRepository)
{

}

Чтобы получить от Unity экземпляр сервиса можно написать такой код:

var container = new UnityContainer();
container
    .RegisterType<ObjectContext, AddressBookEntities>(
            new ContainerControlledLifetimeManager(),
            new InjectionConstructor())
    .RegisterType(typeof(IRepository<>), typeof(EFRepository<>));

var service = container.Resolve<SomeService1>();

Unity сам создаст инстансы конкретных типов при сборке зависимостей SomeService1.

Рефакторинг legacy кода для использования Unity

noreply@blogger.com (gandjustas) — Wed, 21 Jan 2009 08:09:00 +0000

Представим себе код, который был написан без применения принципов IoC.
Например такой

public class AccountManager
{
    public void CreateAccount(string userName, string password)
    {
        var accountStore = new AccountStore();
        accountStore.AddNewAccount(userName, password);
    }

    public bool Authenticate(string userName, string password)
    {
        var accountStore = new AccountStore();
        if (accountStore.IsValidAccount(userName, password))
        {
            Session.CurrentSession.SetAuthToken(userName);
            return true;
        }
        else
        {
            return false;
        }
    }

    public bool IsUserInRole(string userName, string roleName)
    {
        var roleStore = new RoleStore();
        return roleStore
                .GetRolesForUser(userName)
                .Contains(roleName);
    }
}

Классы AccountStore и RoleStore – это персистентные хранилища, а класс Session хранит информацию о текущем сеансе работы пользователя.

Класс AccountManager применяется во многих местах, поэтому мы не можем сразу вынести все зависимости в конструктор.

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

public class AccountManager
{
    [Dependency]
    public AccountStore AccountStore { get; set; }

    [Dependency]
    public RoleStore RoleStore { get; set; }

    [Dependency("GetCurrentSession")]
    public Func<Session> GetCurrentSession { get; set; }

    public AccountManager()
    {
        AccountStore = new AccountStore();
        RoleStore = new RoleStore();
        GetCurrentSession = () => Session.CurrentSession;
    }

    public void CreateAccount(string userName, string password)
    {
        AccountStore.AddNewAccount(userName, password);
    }

    public bool Authenticate(string userName, string password)
    {
        if (AccountStore.IsValidAccount(userName, password))
        {
            GetCurrentSession().SetAuthToken(userName);
            return true;
        }
        return false;
    }

    public bool IsUserInRole(string userName, string roleName)
    {
        return RoleStore
                .GetRolesForUser(userName)
                .Contains(roleName);
    }
}

В этом коде атрибутами сразу обозначены зависимости. Эти атрибуты будет анализировать Unity при инъекции зависимостей.
Так как при инъекции компоненты подбираются по типу, то для функцции GetCurrentSession желательно указать дополнительный строковый идентификатор.

Теперь будем прикручивать IoC-контейнер.
Нам сначала понадобится создать синглтон контейнера Unity.
Многие, в том числе и я, считают синглтоны злом, но в данном случае немного зла необходимо.

public static class UnitySingleton
{
    static IUnityContainer _instance = new UnityContainer();

    public static UnitySingleton()
    {
	//Здесь будем конфигурировать контейнер
        _instance
            .RegisterType<AccountStore>()
            .RegisterType<RoleStore>()
            .RegisterInstance<Func<Session>>(
                    "GetCurrentSession",
                    () => Session.CurrentSession);
    }

    public static IUnityContainer Instance
    {
        get
        {
            return _instance;
        }
    }
}

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

Теперь в конструкторе AccountManager напишем только одну строчку

public AccountManager()
{
    UnitySingleton.Instance.BuildUp(this);
}

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

Когда сам класс AccountManager нигде не будет инстанцироваться явно через new, а только доставаться из контейнера, тогда можно будет рефакторить AccountManager, чтобы он получал все зависимости через конструктор.

Используем IoC-контейнер Unity

noreply@blogger.com (gandjustas) — Tue, 20 Jan 2009 21:22:00 +0000

Unity – IoC-контейнер от Microsoft, разработанный группой Patterns&Practicies. Найти его можно по адресу http://www.codeplex.com/unity. Также Unity включен в состав Enterprise Library.

Будет использоваться версия 1.2, последняя на данный момент.

Итак приступим.
Как завещал дядька Фаулер будем рассматривать использования контейнера на примере программы, работающей с базой данных фильмов.

Чтобы использовать Unity в своей программе надо подключить сборки Microsoft.Practices.ObjectBuilder2 и Microsoft.Practices.Unity.

Нам надо написать класс, который позволяет искать фильмы по различным параметрам.

Предположим что фильмы описываются классом Movie

public class Movie
{
    public string Title { get; set; }
    public string Director { get; set; }
    public int Year { get; set; }
}

Работу с БД завернем в интерфейс

public interface IMovieRepository
{
    IQueryable<Movie> GetMovies();
}

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

public class MovieFinder
{
    IMovieRepository _repository;

    public MovieFinder(IMovieRepository repository)
    {
        _repository = repository;
    }

    public IEnumerable<Movie> FindByTitle(string q)
    {
        return _repository
                .GetMovies()
                .Where(m => m.Title.Contains(q));
    }
}

В целях тестирования напишем простую реализацию IMovieRepository.

public class InMemoryMovieRepository : IMovieRepository
{
    public IQueryable<Movie> GetMovies()
    {
        return new[]
        {
            new Movie
            {
                Title = "Гарри Поттер и узник Азкабана",
                Director = "Альфонсо Куарон",
                Year = 2004
            },
            new Movie
            {
                Title = "Звездные войны: Эпизод 2 - Атака клонов",
                Director = "Джордж Лукас",
                Year = 2002
            },
            new Movie
            {
                Title = "Властелин колец: Братство кольца",
                Director = "Питер Джексон",
                Year = 2001
            },
        }.AsQueryable();
    }
}

Напишем короткий код, который собирает все вместе.

//Создаем контейнер
var container = new UnityContainer();

//Помещаем в контейнер реализацию для используемого интерфейса
container.RegisterType<IMovieRepository, InMemoryMovieRepository>();

//Собираем нужный объект
var finder = container.Resolve<MovieFinder>();

Обратите внимание, что сам тип MovieFinder необязательно помещать в контейнер.

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

Реализация IMovieRepository для БД будет выглядеть так:

public class EFMovieRepository: IMovieRepository
{
    MoviesContainer _context;

    public EFMovieRepository(MoviesContainer context)
    {
        _context = context;
    }

    public IQueryable<Movie> GetMovies()
    {
        return _context.Movies;
    }
}

Где MoviesContainer – тип контекста EF.

Чтобы использовать этот репозитарий слегка изменим код основной программы.

var container = new UnityContainer();
container
    .RegisterType<IMovieRepository, EFMovieRepository>()
    .RegisterType<MoviesContainer>(new InjectionConstructor());

var finder = container.Resolve<MovieFinder>();

Параметр new InjectionConstructor() для второго вызова RegisterType говорит контейнеру что надо использовать конструктор без параметров для создания объекта этого класса. Если конструктор в классе всего один, то задавать такой параметр не требуется.

В приведенном выше коде есть один недостаток. Все объекты создаются каждый раз при вызове Resolve. Если мы не хотим пересоздавать каждый раз контекст EF (это длительная операция), то можем сделать его синглтоном.
Делается это очень просто, достаточно заменить вызов
.RegisterType<MoviesContainer>(new InjectionConstructor())
на
.RegisterType<MoviesContainer>(
new ContainerControlledLifetimeManager(),
new InjectionConstructor())

Первый параметр задает LifetimeManager, который, как понятно из названия, управляет временем жизни объекта. ContainerControlledLifetimeManager означает что объект будет жить пока живет контейнер, и для всех вызовов Resolve будет возвращаться один и тот же экземпляр контекста.

В принципе этого достаточно чтобы начать использовать Unity в своем проекте.

Основная задача IoC-контейнеров

noreply@blogger.com (gandjustas) — Tue, 20 Jan 2009 09:56:00 +0000

Многократно встречал мнение что использовать IoC-контейнер стоит только тогда, когда нужно изменение конфигурации без перекомпиляции программы.
Такое мнение пришло из мира Java, где частью любой крупной программы является множество конфигурационных XML файлов. В других платформах зачастую возможность внешнего конфигурирования используемых компонент избыточна.

На самом деле основной задачей IoC-контейнеров является декларативное управление временем жизни компонент, и зависимостями между ними.

Внешние конфиги, позволяющие менять состав компонент без перекомпиляции, AOP времени исполнения и другие приблуды являются необязательными.

Введение в IoC

noreply@blogger.com (gandjustas) — Mon, 19 Jan 2009 19:03:00 +0000

(Пост на RSDN)

Есть класс A и зависит от от класса B (использует его).

Например так:

public class A
{
   B b = new B();
   void foo()
   { 
      //используем b
   }
}

public class B
{
    ...
}

В этом коде существует несколько проблем.
1)Невозможно тестировать класс A в отрыве от B. Если B работает с БД, то для тестов A вам понадобится база.
2)Временем жизни объекта B управляет А, нельзя например использовать один и тот же объект B в разных местах.

Чтобы победить это нам сначало надо выделить интерфейс B и назвать его IB.

public interface IB
{
    ...
}

public class A
{
    IB b = new B();    
  
    void foo()  
    {    
        //используем b  
    }
}

public class B:IB
{
    ...
}

Но ни одну из наших проблем это не решило.

Теперь можно применить паттерн Service Locator. Суть этого паттерна состоит в том что имеем фабричный метод который по идентификатору возвращает нужную реализацию интерфейса. В .NET есть IServiceProvider с одном методом GetService, которому параметром передается тип.

Предположим что мы сделали хорошую реализацию IServiceProvider и у нас получился такой код

public interface IB
{
    ...
}
public class A
{
    //serviceLocator - реалзиация IServiceProvider
    //которая по типу IB возвращает B
    IB b = (IB)serviceLocator.GetService(typeof(IB)); 
   
    void foo()  
    {
        //используем b
    }
}

public class B:IB
{
    ...
}

Теперь временем жизни B управляет serviceLocator, A не знает о классе B. Можно через serviceLocator подпихнуть любую реализацию IB.
Этот подход называет Dependency Lookup — поиск зависимостей, это один из вариантов подхода IoC.

Но у нас появилась зависимость от serviceLocator, теперь хоть тестировать A без класса B возможно, но это потребует настройки локатора (возможно совсем нетривиальной).

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

public interface IB
{
    ...
}

public class A
{    
    IB b;    
    
    //Например так  
    public A(IB b)
    {
        this.b = b;
    }

    //Или так  
    public IB B { {get {return b;} set {b = value;}}  

    //Или так  
    public void SetB(IB b)
    {
        this.b = b;
    }  
    
    void foo()
    {    
        //используем b
    }
}

public class B:IB
{
    ...
}

Тогда вызывающий код дожен выгядеть примерно так

...
var a = new A(new B());
...

Теперь у нас A не зависит ни от чего, а все зависимости можно передать например через конструктор, что значительно облегчает тестирование A.
Этот подход называется Dependency Injection — инъекция зависимостей, это другой вариант IoC.

Но в большем масштабе проблемы не решает, только перемещает её на уровень выше, то есть все зависимости перемещаются в вызывающий код.

Если такой подход применить во всей программе, то в итоге метод main (или другая точка входа) будет выглядеть так:

new Program(new A(new B(new C(), new D()), new E()......)

И это мы еще не рассматривали управление временем жизни объектов.

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

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

container.Resolve<program>();

А также потребуется где-то задать параметры контейнеру, чтобы он по запросу объекта типа IB возвращал объект типа B, для IA возвращал A и так далее.
Обычно параметры контейнера можно задавать как в коде, так и во внешнем конфигурационном файле.

Кроме того IoC-контейнер можно использовать как Service Locator, но такого надо избегать.

Для .NET существует множество контейнеров. От MS — Unity, даже версия для Silverlight уже появилась, autofac, Castle Windsor, StructureMap и Spring.NET. Spring.NET — клон java библиотеки со всеми вытекающими. Куча конфигов в XML, огромное число классов в библиотеке, слабое использование возможностей .NET, лично меня от него воротит после использования достаточно легковесного unity.

Кроме того MS ведет разработку библиотеки MEF. В ней применяются принципы IoC, но для более крупных компонент, а также возможности менять набор компонент в Runtime. MEF будет в составе .NET 4.0