问题标签 [dependency-injection]

哪些 C#/.NET 依赖注入框架值得研究？关于它们的复杂性和速度，你能说什么。

我最近一直在使用 StructureMap，并且非常享受这种体验。但是，我可以看到一个人很容易被接口所有东西所迷惑，并最终得到将大量接口引入其构造函数的类。尽管在使用依赖注入框架时这确实不是一个大问题，但它仍然觉得有些属性真的不需要仅仅为了接口而被接口出来。

您在哪里画出接口与仅向类添加属性的界限？

我正在使用 Castle Windsor 进行一些依赖注入，特别是我已将 DAL 层抽象为现在由 DI 加载的接口。

一旦项目被开发和部署，所有 .bin 文件都将位于同一位置，但是当我在 Visual Studio 中开发时，我能看到的唯一方法是将依赖注入项目的 .bin 文件放入启动项目的 bin文件夹要么有一个将其复制进去的构建后事件，要么是手动引用 DAL 项目以将文件拉入。

我对这两种解决方案都不完全满意，所以我想知道是否有解决这个问题的“标准”方法？

有不利的一面吗？我现在感觉几乎依赖它了。每当项目超过一定规模时，几乎都会对标准模式产生过敏反应，并立即使用依赖注入框架重新连接它。

我发现的最大问题是它可能会让其他刚刚学习它的开发人员感到困惑。

另外，如果它是我使用的语言的一部分，我会感觉好多了。不过，至少对于 Java，有几个非常轻量级的库非常好。

想法？糟糕的经历？或者只是停止担心它？

[编辑] 回复：依赖注入本身的描述

抱歉含糊其辞。Martin Fowler对它的描述可能比我以往任何时候都好……无需浪费精​​力。

巧合的是，这证实了一点，即它仍然没有得到广泛的实践，如果每个人都没有跟上进度，在与团队合作时可能会成为障碍。

我绝对需要使用 IoC 容器来解耦日益复杂的企业服务系统中的依赖关系。我面临的问题与配置（又名注册）有关。我们目前有 4 种不同的环境——从开发到生产以及介于两者之间。这些环境有许多配置，因环境而异；然而，在我目前能想到的所有情况下，组件之间的依赖关系不会因环境而异，尽管我可能遗漏了一些东西和/或这显然会改变。

所以，最终的问题是，有没有人有使用 IoC 框架的类似经验？或者，任何人都可以推荐一个框架而不是另一个框架，它可以通过某种约定或简化的配置信息提供灵活的注册？我是否仍然能够从流畅的界面中受益，或者我是否坚持使用 XML——我想避免 XML 地狱。

编辑：这是一个 .Net 环境，我一直在研究 Windsor、Ninject 和 Autofac。它们现在似乎都支持两种注册方法（fluent 和 XML），尽管 Autofac 对 lambda 表达式的支持似乎与其他方法有点不同。有人在类似的多部署环境中使用它吗？

I've got a solution with several different projects in it, some are pure class libraries and some are web app projects. If I want my default types to be available to all projects, where should I put the config file for the container?

我在我的测试项目中使用 Castle Windsor 进行依赖注入。我正在尝试创建我的“存储库”类之一的实例。“它在我的机器上运行良好”，但是当我在 TFS 中运行每晚构建时，我的测试无法加载所述类。

xml配置：

当我对新构建进行排队时，它会产生以下消息：

无法创建类 Example2008.Test.ActiveProductRepositoryTest 的实例。错误：System.Configuration.ConfigurationException：找不到类型名称 Example2008.Repository.LALALALALA，Example2008.Repository。

Castle.Windsor.Installer.DefaultComponentInstaller.ObtainType(String typeName) Castle.Windsor.Installer.DefaultComponentInstaller.SetUpComponents(IConfiguration[] 配置，IWindsorContainer 容器) Castle.Windsor.Installer.DefaultComponentInstaller.SetUp(IWindsorContainer 容器，IConfigurationStore 存储) Castle.Windsor .WindsorContainer.RunInstaller() Castle.Windsor.WindsorContainer..ctor(IConfigurationInterpreter 解释器) Example2008.Test.ActiveProductRepositoryTest..cctor() in d:\Code_Temp\Example Project Nightly\Sources\Example2008.Test\ProductRepositoryTest.cs：第 19 行

从这条消息看来，我的配置是正确的（可以看出我要实例化具体类'LALALALALA'，所以xml配置明显已经正确的红色了）

我认为我的依赖项设置也正确（因为它在本地工作，即使我清理解决方案并重建）。

有什么想法吗？

（顺便说一句，使用 VS2008、TFS 2008.Net 3.5、Castle 1.03）

MEF（Managed Extensibility Framework）解决了哪些现有IoC/DI容器无法解决的问题？

我正在将城堡温莎用于我正在从事的宠物项目。我开始注意到我需要在代码的不同位置调用 IoC 容器来创建新对象。这种对容器的依赖使我的代码更难维护。

我用过两种解决方案来解决这个问题

我尝试创建抽象工厂作为容器的包装器，我可以将其注入需要创建对象的应用程序部分。这可行但有一些缺点，因为城堡很难将自己的容器作为依赖项注入。所以我必须手动完成，这违背了 IoC 容器的全部目的。

我使用主 applicationcontroller 类来包装 IoC 容器并作为中央工厂/存储库工作。这是相当成功的，但是这个类变得太大了，就像一个中心上帝对象，几乎所有其他对象都有对它的引用。

两种解决方案都有效，但都有其缺点。所以我很好奇其他人是否有同样的问题并找到了更好的解决方案。

编辑 问题不在于依赖于对象B的对象A。在这里我通常只使用构造函数注入并且一切正常。有时我有类型 A 的对象需要在其生命周期内创建可变数量的其他类型 B 的对象。我不知道该怎么做。

@Blair Conrad：到目前为止，维护问题并不严重。我有一些类依赖于容器对象调用 container.Resolve<>。而且我不想让我的代码取决于我认为的基础设施。我仍在尝试，所以我注意到在从 ninject 切换到 Castle 时，我必须更改很多代码。

@花：嗯。我喜欢你的拳头解决方案。它结合了我尝试过的两种解决方案的工作原理。我想我仍然在对象方面考虑太多，而在接口/职责方面考虑得不够。我尝试了专门建造的工厂，但我想让他们在幕后使用容器来创建对象，但我还没有发现如何以干净的方式将容器 DI 转换为对象。

我是一名长期的 Windows 开发人员，对 win32 和早期的 COM 有过初步了解。自 2001 年以来，我一直在使用 .NET，因此我非常精通 C# 和 CLR。在我开始参加 Stack Overflow 之前，我从未听说过温莎城堡。我已经阅读了温莎城堡的“入门”指南，但没有点击。

教这条老狗新技巧，并告诉我为什么要将 Castle Windsor 集成到我的企业应用程序中。