NInject 和 MVC 3 - 我应该使用 DependencyResolver 而不是 [Inject] 属性吗？

发布于 2024-10-17 20:40:14 字数 655 浏览 3 评论 0原文

最近我转向了 MVC 3 和 Ninject 2。在大多数代码中，我使用构造函数注入，但有些地方我必须使用 Inject 属性。 Ninject 2 注册了自己的 IDepencyResolver 接口。我不喜欢 DependencyResolver 类成为 System.Web.Mvc 命名空间的一部分，因为它的功能与 MVC 并不严格相关，但是现在，当它存在时，做

public SomeClass 
{
    public IUserService UserService { get; set; }

    public SomeClass()
    {
        UserService = DependencyResolver.Current.GetService<IUserService>();

我可以这样

public SomeClass 
{
    [Inject]
    public IUserService UserService { get; set; }

，这样我就不必在我的类中引用 Ninject 命名空间。 DependencyResolver 应该这样使用吗？

原文

Recently I moved to MVC 3 and Ninject 2. In most of the code, I use constructor injection, but there are some places, where I had to use Inject attribute. Ninject 2 registers its own IDepencyResolver interface. I don't like DependencyResolver class being part of System.Web.Mvc namespace, because its function is not really strictly related to MVC, but now, when it is there, I can do

public SomeClass 
{
    public IUserService UserService { get; set; }

    public SomeClass()
    {
        UserService = DependencyResolver.Current.GetService<IUserService>();

instead of

public SomeClass 
{
    [Inject]
    public IUserService UserService { get; set; }

so I don't have to reference Ninject namespace in my classes. Should DependencyResolver be used like that?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

寒尘 2024-10-24 20:40:14

我仅将属性注入用于类正常工作不需要的依赖项，但如果用户设置它们，则可以添加一些功能。此类功能的示例是日志记录。因此，您可以拥有一个代表记录器的属性，用户可以在其中提供自己的实现，如果他不提供，该类将继续正常工作，但它根本不会记录。

对于其他一切，我使用构造函数注入。通过这种方式，您可以向消费者表明该类对某些其他服务具有必需的依赖关系。

因此，要回答您有关属性注入的问题，我只需：

public SomeClass 
{
    public IUserService UserService { get; set; }

    public void SomeMethodWhichDoesntEnforceUserService()
    {
        if (UserService != null)
        {
            // Provide some additional functionality
        }
    }
}

如果您的类在没有用户服务的情况下无法正常运行：

public SomeClass 
{
    private readonly IUserService _userService;
    public SomeClass(IUserService userService)
    {
        _userService = userService;
    }

    public void SomeMethodWhichRequiresTheService()
    {
        _userService.DoSomething();
    }
}

因此，在这两种情况下都没有引用任何 DI 细节。这就是控制反转的意义所在。

I use property injection only for dependencies that are not required for the proper working of the class but could add some functionality if the user sets them. Example of such functionality is logging. So you could have a property which represents a logger where the user can supply his own implementation and if he doesn't the class continues to work normally but it simply doesn't log.

For everything else I use constructor injection. This way you indicate to the consumer that this class has a required dependency on some other service.

So to answer your question about the property injection I would simply have:

public SomeClass 
{
    public IUserService UserService { get; set; }

    public void SomeMethodWhichDoesntEnforceUserService()
    {
        if (UserService != null)
        {
            // Provide some additional functionality
        }
    }
}

and if your class cannot function properly without the user service:

public SomeClass 
{
    private readonly IUserService _userService;
    public SomeClass(IUserService userService)
    {
        _userService = userService;
    }

    public void SomeMethodWhichRequiresTheService()
    {
        _userService.DoSomething();
    }
}

So in both cases no reference to any DI specifics. That's what Inversion of Control is all about.

回复收藏 0 原文