是否適合在類型綁定DI框架中實現業務邏輯？

public IRedirect FactoryStrategyRedirect() 
{ 
    if (_PasswordExpired) { 
    return _UpdatePasswordRedirectorFactory.Create(); 
    } else { 
    return _DefaultRedirectorFactory.Create(); 
    } 
}

這種策略工廠方法可以與類型綁定，當更換條款：是否適合在類型綁定DI框架中實現業務邏輯？

Bind<IRedirect>.To<UpdatePasswordRedirector>.When(c=> c.kernel.get<SomeContext>().PasswordExpired()) 
Bind<IRedirect>.To<DefaultRedirector>.When(c=> not c.kernel.get<SomeContext>().PasswordExpired())

我不知道這兩種方法是比較正確的。優缺點都有什麼。

特別是在邏輯更復雜的情況下，需要測試更多變量以及更多具體的類才能返回。

是否正確地在綁定中實現業務邏輯？

來源

2013-08-02 Martino

我會說，在任何情況下，你應該防止你的Composition Root內有業務邏輯。你的組成根應該正確地佈線，並且你想要進行集成測試來測試這種佈線的正確性。

應用程序代碼應該全部關於業務邏輯，您應該有單元測試來驗證業務邏輯。

雖然在你的情況下，差異可能是微不足道的，線條開始變得很模糊，而且最終會出現一個複雜，難以閱讀和難以維護的複合根。

來源

2013-08-04 20:24:36 Steven

我完全同意。有人可能會添加一個信號燈，當「組合根」是動態的時候，如上例所示，使用經典的AbstractFactory來實現它會很好嗎？ – Martino

你是什麼意思的動態組合根？請注意，抽象工廠模式在應用依賴注入時仍然是一個非常有效的模式。 – Steven

對不起，但也許更正確的終點是「動態對象圖」。我的意思是在運行時爲相同的根對象存在多個對象圖。在運行時依賴於上下文而不是由配置變量來選擇對象praph的「歧視性」。 – Martino

是否適合在類型綁定DI框架中實現業務邏輯？

回答

相關問題