根据公约与Ninject的构造函数的字符串参数绑定 [英] Convention based binding of constructor string arguments with Ninject

查看:281
本文介绍了根据公约与Ninject的构造函数的字符串参数绑定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用Ninject作为我的项目IoC容器。我有以下类:

I'm using Ninject as IoC container in my project. I have following class:

public class SomeRepository:ISomeRepository
{
    public SomeRepository(string someDatabaseConnectionString)
    {
        // some code here..
    }
}

在我的应用程序的设置文件我有一个名为someDatabase连接字符串。默认情况下,应该以注入此连接字符串到构造函数中添加以下配置:

In my application settings file I have connection string named "someDatabase". By default the one should add following configuration in order to inject this connection string into the constructor:

kernel.Bind<ISomeRepository>()
    .To<SomeRepository>()
    .WithConstructorArgument("someDatabaseConnectionString", connString);



但我想基于这样的字符串绑定来实现传统。对于字符串类型名称以的ConnectionString结尾的所有构造函数的参数值应根据应用程序的是connectionStrings配置部分采取并自动注入。我想落实的appSettings部分类似约定好。这种方法更详细的马克·西曼的原始相关性文章(原语约定部分)。在实施例中使用温莎城堡容器。

But i want to implement conventional based binding of such strings. Values for all constructor parameters of string type that names ends with "ConnectionString" should be taken from application's connectionStrings configuration section and injected automatically. I want to implement similar convention for appSettings section as well. This approach described in greater details in Mark Seeman's "Primitive Dependencies" article ("Conventions for primitives" section). Castle Windsor container was used in examples.

是否有可能使用Ninject来实现这些公约的,什么是做到这一点的最好方法是什么?我已经尝试ninject.extensions.conventions,但似乎并不具有这样的功能,不是吗?

Is it possible to implement such conventions using Ninject and what is the best way to do this? I have already tried ninject.extensions.conventions but seems it doesn't has such a functionality, does it?

推荐答案

一点也没有T看起来像一种基于约定绑定的是可能的Ninject现在。 我这里也有类似的问题和建议是作出接口返回连接字符串和具有作为参数。 。这可能是因为尽管许多不同的连接字符串繁琐

It doesn't look like that kind of convention-based bindings is possible with Ninject right now. I had a similar question here and the suggestion was to make an interface to return the connection string and have that as the parameter. That could be tedious for many different connection strings though.

这只是一个想法,但你可以有一个 IConnectionStringProvider< T>
,可以使用反射来获得T的名称和查找应用程序设置呀?也许是这样的:

This is just a thought, but could you have an IConnectionStringProvider<T> that could use reflection to get the name of T and look up the application setting that way? Maybe like this:

public class ConnectionStringProvider<T> : IConnectionStringProvider<T>
{
    public string Value
    {
        // use reflection to get name of T
        // look up connection string based on the name
        // return the connection string
    }
}
...
public class SomeRepository:ISomeRepository
{
    public SomeRepository(IConnectionStringProvider<SomeRepository> connectionStringProvider)
    {
        this.connectionString = connectionStringProvider.Value;
    }
}



此外,如果不工作,你可以有非泛型 IConnectionStringProvider 接受一个类型作为参数:

Also if that doesn't work, you could have a non-generic IConnectionStringProvider that takes a type as the argument:

public class ConnectionStringProvider : IConnectionStringProvider
{
    public string GetValueFor(Type type)
    {
        // use reflection to get name of type
        // look up connection string based on the name
        // return the connection string
    }
}
...
public class SomeRepository:ISomeRepository
{
    public SomeRepository(IConnectionStringProvider connectionStringProvider)
    {
        this.connectionString = connectionStringProvider.GetValueFor(this.GetType());
    }
}

如果这些作品之一,那么他们将有优势他们应该与任何DI容器的工作。

If one of these works then they would have the advantage that they should work with any DI container.

这篇关于根据公约与Ninject的构造函数的字符串参数绑定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆