使用Simple Injector将构造函数传递给构造函数abd WebFormsMVP

Question

我试图将SimpleInjector与WebFormsMvp相结合。

为了方便DI WebFormsMvp提供了IPresenterFactory接口。
它包含Create方法，该方法提供演示者类型以解析和视图实例。
我需要注入的视图实例为的构造的主持人。
主持人也有其他依赖关系需要创建容器。

这是我到目前为止，但它并不理想。
什么是正确的解决方案的问题？

主讲构造：

public FooPresenter(IFooView view, IClientFactory clientFactory) : base(view) 

厂：

public class SimpleInjectorPresenterFactory : IPresenterFactory 
{ 
    private readonly Container _container; 
    private IView _currentView; 

    public SimpleInjectorPresenterFactory() 
    { 
     _container = new Container(); 

     Func<Type, bool> isIView = 
      type => typeof(IView).IsAssignableFrom(type); 

     _container.ResolveUnregisteredType += (s, e) => { 
      if (isIView(e.UnregisteredServiceType)) 
       e.Register(() => _currentView); 
     }; 
    } 

    public IPresenter Create(Type presenterType, Type viewType, IView viewInstance) 
    { 
     lock (_currentView) 
     { 
      _currentView = viewInstance; 
      return _container.GetInstance(presenterType) as IPresenter; 
     } 
    } 
} 

Answer 1

WebFormsMvp迫使你采取在主持人的构造函数的观点，但是这会触发循环引用。如果您查看不同容器的工厂实现，您会看到，对于每个容器，他们都会在设计中采用不同的技巧来解决这个问题。例如，使用unity时，他们创建一个子容器并在子容器中注册该视图，并使用该子容器解析演示者。相当奇怪和性能沉重。

WebFormsMvp的设计者应该在IPresenter接口上使视图成为可写属性，而不是在呈现器的构造函数中使用视图。这会让主持人的观点变得难以置信。事情是这样的：

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

遗憾的是他们并没有这样做，这是不可能的扩展设计，让这个（没有做使用反射真的讨厌的东西）。

简单喷油器不支持向GetInstance()方法提供构造函数参数。出于好的理由，因为这通常会导致Service Locator反模式，并且您可以随时通过更改设计来解决此问题。就你而言，你并没有做出这种古怪的设计，所以你不能改变它。

你对ResolveUnregisteredType做了什么很聪明。我不会想到这件事。由于我是简单注射器背后的主要开发人员，因此我可以说您所做的确实非常聪明:-)

只需提供关于您的SimpleInjectorPresenterFactory的两点反馈意见。

首先，你应该提供Container作为构造函数的参数，因为这将是非常可能的，你需要给其他注册加入到容器中，并且你不想注册SimpleInjectorPresenterFactory内Container。

其次，您可以通过使用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的实施，你看到很多缓存在那里往前走。我不知道他们为什么这么做，但从性能的角度来看，根本不需要这种简单的喷油器。也许我错过了一些东西，但我不明白为什么应该有一个缓存。

但更糟的是，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不可变，这意味着您创建原始字典的副本，添加新值并替换用新的参考旧字典。但是，在这种情况下，我可能会锁定整个事情。

这是一个有点题外话，但只是想告诉:-)