2

所以我开始使用 Ninject 进行依赖注入，我想知道人们如何看待使用内核作为工作单元类型对象（如 Linq2Sql Datacontexts）的对象工厂。我会像普通依赖项一样注入它们，但这会引入一些我想避免的对象生命周期问题。DataContexts 与一般依赖项不同，因为您应该根据需要启动新实例并在完成后处理它们。

要做这样的事情，我只需像这样设置一个提供程序......

class SomeDataContextProvider : Provider<SomeDataContext>
{
    private static string _connectionString = "someConnectionString"
    protected override SomeDataContext CreateInstance(IContext context)
    {
        return new SomeDataContext(_connectionString);
    }
}

将它们绑定在一个模块中......

class MyModule : Ninject.Modules.NinjectModule
{
    public override void Load()
    {
        Bind<SomeDataContext>().ToProvider(SomeDataContextProvider);
    }
}

并在需要时使用标准内核...

class MyClassThatNeedsADataContext
{
    private StandardKernel _kernel = new StandardKernel(new MyModule());

    public void SomeMethod()
    {
        using (var db = _kernel.Get<SomeDataContext>())
        {
            //Use the context
        }
    }
}

对于本质上是静态工厂的东西来说似乎有点沉重，但无论如何我都在使用 Ninject 来处理其他东西。我喜欢它为团队成员提供工厂约定，而不是让他们随意使用（在奇怪的地方创建一堆不同的工厂类，或者只是在对象上放置静态方法等）。

想法？有没有更好的方法来使用依赖注入来处理工作单元依赖项，如 DataContexts 或 WCF 服务客户端？

4

1 回答 1

6

我不喜欢将容器注入类，因为它会在您的应用程序和容器之间创建依赖关系，并且不太清楚类具有哪些依赖关系。我真的不明白这种方法如何比工厂获得任何好处，所以我个人会创建一个“DataContextFactory”并将其注入到任何需要访问数据库的类中。

于 2009-11-17T20:36:12.663 回答