有誰知道是否有可能使用Ninject解決實例化過程之外的任何未解決的抽象依賴關係?我剛剛查看了構造函數注入vs屬性/方法/字段注入,但它看起來好像Ninject仍然期望使用IKernel.Get <>()方法創建該類型。對象初始化後Ninject是否可以解析抽象依賴關係?
基本上,我們使用MVC3來構建我們的產品,我們想到了默認的ModelBinder將表單值映射到對象實例然後能夠調用方法的情況在提交的ViewModel上依賴於抽象接口,例如
public class InviteFriend {
[Required]
public string EmailAddress { get; set; }
public void Execute() {
var user = IUserRepository.GetUser(this.EmailAddress);
if (user == null) {
IUserRepository.SaveInvite(this.EmailAddress);
}
MailMessage toSend = new MailMessage(); // Obviously some logic to prepare the body, subject and other mail properties
SmtpClient.Send(toSend);
}
}
其中控制器操作將接收InviteFriend作爲方法參數。我們希望Ninject能夠解決IUserRepository依賴,但我不能完全解決如何,因爲對象本身是由MVC模型綁定器,而不是Ninject IKernel.Get <>()實例化。
也許該解決方案是基於Ninject-ModelBinder的,或者這是否顯得非常糟糕的主意?
編輯添加:經過下面的評論,我意識到我的匆忙模擬代碼示例並不真正反映我們面臨的。我更新了代碼示例以反映InviteFriend.Execute()的邏輯比調用一個存儲庫上的方法更復雜。潛在地,這是表示可以協調多個不同域對象和多個存儲庫之間的交互的離散任務的邏輯。存儲庫被抽象地定義,理想情況下將由Ninject解決。
我覺得這是好主意,在模型這樣的方法 - 任何數據操作應由控制器完成。模型只應代表數據和數據。 – 2011-04-27 14:55:15
我同意Lukas所說的控制器應該有IUserRepository和InviteFriend類應該只做它應該做的事:表示用戶輸入數據。 – 2011-04-27 21:09:10
這會不會導致胖控制器呢?我的想法是,在ViewModel中使用這種邏輯,或者更好地稱爲命令式對象,可以將業務邏輯保留在域對象中,然後更容易重用,而不是將業務邏輯有效地放入Controller操作方法中留下複製粘貼樣式代碼重用的範圍。通過這種方式,Silverlight/WP7應用程序可以重複使用相同的命令式對象,而不需要爲相同的邏輯複製代碼... – jonsidnell 2011-04-27 21:55:10