簡體   English   中英

使用StructureMap將相同接口的不同實現注入到控制器中的最佳方法是什么?

[英]What's the best way to inject different implementations of the same interface in to a controller using StructureMap?

我對StructureMap相當陌生,但是我的理解是,有兩種方法可以從ObjectFactory獲取實例:

  1. 按類型(即ObjectFactory.GetInstance<IFoo>()
  2. 通過類型和名稱(即ObjectFactory.GetNamedInstance<IFoo>("foo.bar")

我已經看到了許多示例,這些示例演示了如何創建一個MVC控制器工廠,該工廠將使用StructureMap提供控制器實例,並且在大多數情況下,我已經看到,他們使用的是上述選項#1中的方法。

假設我們有一些控制器接受存儲庫/ DAO接口作為構造函數arg ...

public class FooController : Controller
{
  public FooController (IFooRepository fooRepository)
  {
     // constructor code goes here
  }
}

使用接口類使我能夠將該接口的任何實現“注入”到我的控制器中。 如果對於兩個不同的操作,我想注入不同的實現怎么辦? 也許在一種情況下,我需要實現將查詢SQL Server數據庫的存儲庫的實現,而在另一種情況下,我需要實現將從XML文件或通過Web Service調用獲取數據的實現。

看來,如果您使用ObjectFactory.GetInstance()方法,則將被限制為僅為控制器提供存儲庫接口的單個​​實現。

但是,如果使用命名實例,那么最終將不得不根據MVC框架提供的控制器的名稱來創建實例。 在大多數情況下,這通常是來自URL的控制器名稱,但這實際上取決於路由配置。 這似乎很令人困惑,並且隨着路線數量的增加只會變得更加令人困惑。

是否有其他方法可以使用不同的控制器實例化策略而無需使用命名實例? 僅創建單獨的控制器,並確保任何給定控制器中的所有操作對於存儲庫/ DAO類的相同具體實例都有效,這是一個更好的主意嗎?

對於它的價值,我最終使用命名實例,其中每個實例的名稱都基於MVC框架從URL中提取的控制器的名稱。

例如,URL /foo/DoSomething可能會從ObjectFactory獲取一個IController實例,該實例是使用Repository對象實例化的,該對象使用SqlClient API進行數據訪問。 然后,諸如/foo.webservice/DoSomething的URL將創建相同的具體控制器類的實例,但是將該實例的構造函數傳遞給使用Web服務進行數據訪問的存儲庫對象。

有幾種方法可以覆蓋針對構造函數參數的StructureMap的默認自動裝配行為。 就我而言,我使用了CtorDependencyIs方法,並且具有看起來像這樣的映射...

// create a named instance for the "foo" controller that uses the SqlClient based repository
InstanceOf<IController>()
    .Is.OfConcreteType<FooController>()
    .CtorDependency<IFooRepository>()
    .Is(new FooRepositorySql(Constants.FooConnectionString))
    .WithName("foo");

// create a named instance for the "foo.webservice" controller that uses the Web Service based repository
InstanceOf<IController>()
    .Is.OfConcreteType<FooController>()
    .CtorDependency<IFooRepository>()
    .Is(new FooRepositoryWs(Constants.FooServiceUrl))
    .WithName("foo.webservice");

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM