Передайте значение времени выполнения конструктору, используя Simple Injector abd WebFormsMVP

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

Вместо того, чтобы принимать представление в конструкторе презентатора, разработчики WebFormsMvp должны были сделать представление доступным для записи свойством интерфейса IPresenter. Это сделало бы смущающе легким настроить вид на выступающего. Что-то вроде этого:

public IPresenter Create(Type presenterType, IView view)
{
    var presenter = (IPresenter)_container.GetInstance(presenterType);
    presenter.View = view;
    return presenter;
}   

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

Simple Injector не поддерживает передачу аргументов конструктора в метод GetInstance(). По уважительной причине, так как это обычно приводит к антипаттерну Service Locator, и вы всегда можете обойти это, изменив дизайн. В вашем случае вы не делали этот причудливый дизайн, поэтому вы не можете его изменить.

То, что ты сделал с ResolveUnregisteredType, довольно умно. Сам бы я об этом не подумал. И поскольку я ведущий разработчик Simple Injector, я могу сказать, что то, что вы сделали, было действительно умно :-)

Всего два отзыва о вашем SimpleInjectorPresenterFactory.

Прежде всего, вы должны указать Container в качестве аргумента конструктора, так как весьма вероятно, что вам нужно добавить другие регистрации в контейнер, и вы не хотите регистрировать Container внутри SimpleInjectorPresenterFactory.

Во-вторых, вы можете улучшить код, используя файл System.Threading.ThreadLocal<IView>. Это позволяет избавиться от глобальной блокировки. Блокировка предотвращает одновременное создание любого докладчика, и это может замедлить работу вашего веб-сайта.

Итак, вот переработанная версия:

public class SimpleInjectorPresenterFactory : IPresenterFactory {
    private readonly Container _container;
    private ThreadLocal<IView> _currentView = new ThreadLocal<IView>();

    public SimpleInjectorPresenterFactory(Container container) {
        _container = container;

        _container.ResolveUnregisteredType += (s, e) => {
            if (typeof(IView).IsAssignableFrom(e.UnregisteredServiceType)) {
                e.Register(() => _currentView.Value);
            }
        };
    }

    public IPresenter Create(Type presenterType, Type viewType, 
        IView viewInstance)
    {
        _currentView.Value = viewInstance;

        try {
            return _container.GetInstance(presenterType) as IPresenter;
        } finally {
            // Clear the thread-local value to ensure
            // views can be disposed after the request ends.
            _currentView.Value = null;
        }
    }
}

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

Но что еще хуже, в файле UnityPresenterFactory есть ошибка параллелизма. Взгляните на этот метод:

private Type FindPresenterDescribedViewTypeCached(Type presenter, 
    IView view) 
{
    IntPtr handle = presenter.TypeHandle.Value;
    if (!this.cache.ContainsKey(handle)) 
    {
        lock (this.syncLock)
        {
            if (!this.cache.ContainsKey(handle))
            {
                Type viewType = CreateType(presenter, view);
                this.cache[handle] = viewType;
                return viewType;
            }
        }
    }
    return this.cache[handle];
}

На первый взгляд этот код выглядит нормально, так как реализована блокировка с двойной проверкой. К сожалению, кэш (словарь) читается снаружи блокировки, а обновляется внутри блокировки. Это не потокобезопасно. Вместо этого разработчик должен был либо обернуть все это в блокировку, либо использовать ConcurrentDictionary (только .net 4), либо считать cache неизменяемым, что означает, что вы создаете копию исходного словаря, добавляете новое значение и заменяете ссылка на старый словарь с новым. Однако в этом случае я бы, вероятно, просто заблокировал все это.

Это было немного не по теме, но просто хотел рассказать :-)