仍然在探索新的ASP.NET MVC5,現在使用DI構建!ASP.Net MVC 6:遞歸依賴注入
沒有問題,到目前爲止,我可以注入我的處理程序(我不喜歡這個詞服務,因爲這定義了我一個平臺中立的接口):
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetry(Configuration);
services.Configure<Model.Meta.AppSettings>(Configuration.GetSection("AppSettings"));
services.AddSingleton(typeof(Logic.UserEndPointConfigurationHandler));
services.AddSingleton(typeof(Logic.NetworkHandler));
services.AddMvc();
}
做工精細,還強鍵入配置對象「AppSettings」工作得很好。
此外,控制器中的注入也起作用。 但現在我的塌陷:我分隔的數據訪問我從處理程序,並很明顯,我想將它們注入,以及:
public class UserEndPointConfigurationHandler
{
private readonly DataAccess.UserEndPointAccess _access;
public UserEndPointConfigurationHandler(DataAccess.UserEndPointAccess access)
{
_access = access;
}
但是BAM,UserEndPointAccess不能得到解決。所以,即使我直接向一個無參數構造函數的DI請求,我也需要註冊它。對於這種情況,當然我應該Interface和註冊它們,但是對於我也注入的內部幫助類,這意味着什麼?
根據Docs:http://docs.asp.net/en/latest/fundamentals/dependency-injection.html#recommendations以及我發現的例子,世界上所有人似乎都只是在控制器和某些存儲庫之間進行通信。程序集中的不同抽象層上沒有業務層和類。
微軟DI的方法與完美的Unity是否完全不同,在那裏我可以像我想要的那樣精細地分離出來?
在此先感謝。
馬蒂亞斯
編輯@Nightowl:我這裏補充我的答案,因爲它是一個長一點。 首先,Unity會自動創建實例,如果我請求混凝土類型。這允許我注入類型I註冊和類型,像幫助者類等,我不需要。這種組合使我可以在任何地方使用DI。
另外在你的例子中,我需要知道WebGui中的DataAcces,這非常緊密。那麼,我知道有通過Reflection的解決方案,但是我希望微軟在這個主題上做了些什麼,但是這可能意味着一個變化。
還允許Unity存儲實例或說明如何創建它們,另一個巨大的功能,這是目前缺少的。
也許我只是被寵壞了,DI-圖書館做了些什麼,可能他們也做得很多,但根據我的信息,目前微軟的實施只是一個巨大的降級。