有谁知道是否有可能使用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