问题标签 [dependency-injection]

我正在尝试找出 Windows 工作流基础的内部结构。因此，我们有一些软件组件，我们以工作流的形式将它们交织在一起，无论是基于条件的顺序工作流还是状态机工作流。现在，我在想（我在这里可能错了）这并不同样适用于 IoC + 依赖注入（通过 Unity 或 Spring.net）。什么时候用什么？？我想对了吗？？

哪个 IoC 容器最容易上手。这可能等同于哪些文档拥有最友好的文档。不太担心功能的数量。

我正在使用依赖注入为我正在测试的类之外的代码提供模拟。我发现自己一遍又一遍地编写了很多相同的代码，因为我需要模拟在我想要测试的方法中使用的 AuthProvider、ConfigurationManager 等。该方法包含分支（if-then-else），因此我有多个测试来测试该方法的所有执行路径。我多次实例化每个模拟（在每种测试方法中一次），但我想知道这是否是错误的方法？此外，我对模拟和预设响应提出了期望，这些响应显然主要是复制粘贴，因为在每个方法中都会调用诸如 AuthProvider.Authenticate() 之类的调用

在每种方法中，我都设置了一个模拟存储库，并在每种方法结束时验证了模拟存储库。我是否应该有某种工厂来创建这些模拟以及设置它们的期望和返回值，如果是这样，如何？

为了实现模拟，我正在使用 RhinoMocks。

在 Microsoft Unity 中，您可以从现有 XML 配置配置容器，但有没有相反的方法？从初始化的容器导出相应的 XML 配置？

在我的分析器报告中，我越来越多地看到使用依赖注入进行基于模拟的测试的结果。许多依赖项是静态的，但是因为我们想单独测试方法，所以它们被更改为实例成员，如下例所示：

反过来，大多数时候依赖项还有其他依赖项等等。这导致每次在测试之外进行方法调用时都会实例化（主要是“静态”）对象树。每个对象都非常小（只有几个指针），但树效应将其转化为不断增加的性能影响。

我们对于它可以做些什么呢？

我已经阅读了很多关于依赖注入的文章以及观看了很多视频，但我仍然无法理解它。有没有人有一个很好的类比来解释它？

我看了敏捷之秋截屏的第一部分，仍然有点困惑。

我想声明两个bean并使用Spring依赖注入实例化它们？

但是 Spring 抛出一个异常，说“当前正在创建的 FactoryBean 从 getObject 返回 null”

为什么相互依赖的 bean 布线在这里不起作用？我应该在任何地方指定延迟属性绑定吗？

我正在扩展我的对象属性值差异，但我意识到如果一个对象有太多属性，我可能不想全部区分它们。所以我想出了

这样我就可以标记我希望差异忽略的属性。但是我不想用 [IgnorePropertyDiff] 污染我的域对象。

我的问题是，是否可以使用 IoC（如 Ninject 或其他 IoC）动态注入 [IgnorePropertyDiff]？如果我听起来像个白痴，请执行我，因为我只是一个初级中级 c# 开发人员。提前致谢。

我正在使用框架集成中的 BasePage 和 BaseMaster 在 Web 应用程序上使用 Ninject。我想做的是注入一个对象并在每个会话上创建一个新实例。我查看了 OnePerRequest 行为，它很接近，但并不完全。我正在做的是执行大量计算，这些变量保存在注入页面的对象中。我需要这些对象保留以进行回发，但是每次用户“访问”该站点时，我都想要一个新的对象实例。我最初的想法是以某种方式使用 Asp.net Session 对象来存储回发之间的值，这是我在 Ninject 之前会这样做的方式（只是将对象存储在会话中。但我想在如果可以的话，正确的方法。我 我愿意接受其他建议。我考虑过使用单例，但每个用户都需要自己的对象副本，否则他们会相互计算。

我希望这很清楚，对于使用现有行为或创建自己的行为的任何建议，我将不胜感激。也许使用应用程序缓存或内置的 ASP.NET 缓存可以工作。

谢谢

乔什

随着我们依赖注入框架的最新添加（春季注释），创建 DI 管理组件的边际成本似乎已经达到了一些关键的新阈值。虽然以前有与 spring 相关的开销（大量的 XML 和额外的间接），但依赖注入似乎已经开始出现在许多模式所在的地方；他们进入引擎盖并“消失”。

这样做的结果是与大量组件相关的概念开销变得可以接受。有争议的是，我们可以创建一个系统，其中大多数类只公开一个公共方法，并通过疯狂地聚合这些部分来构建整个系统。在我们的例子中，给出了一些东西；应用程序的用户界面有一些功能需求，这些需求塑造了最顶层的服务。后端系统控制下部。但是在这两者之间，一切都可以争夺。

我们经常讨论的是为什么我们要在类中分组，原则应该是什么？有几件事是确定的；立面图案已死并被掩埋。任何包含多个不相关功能的服务也往往会被拆分。“不相关的特征”的解释比我之前所做的要严格得多。

在我们的团队中，这里有两种流行的思路：实现依赖限制分组；单个类中的任何功能最好是所有注入依赖项的客户端。我们是一个 DDD 项目，而另一部分则认为域限制了分组（CustomerService 或更细粒度的 CustomerProductService、CustomerOrderService）——注入依赖项的规范化使用并不重要。

那么在松散耦合的 DI 世界中，为什么我们将逻辑分组到类中？

编辑：duffymo 指出这可能正在朝着函数式编程风格发展；这就提出了国家的问题。我们有相当多的“状态”对象代表相关应用程序状态的（小）片段。我们将这些注入到任何对该状态有合法需求的服务中。（我们使用“状态”对象而不是常规域对象的原因是 spring 在未指定的时间构造这些对象。我认为这是一个轻微的解决方法或替代解决方案，让 spring 管理域对象的实际创建。可能有更好的解决方案这里）。

因此，例如，任何需要 OrderSystemAccessControlState 的服务都可以注入它，而消费者并不容易知道这些数据的范围。一些与安全相关的状态通常用于许多不同的级别，但在中间的级别上完全不可见。我真的认为这从根本上违反了功能原则。从 OO 的角度来看，我什至很难适应这个概念——但只要注入的状态是精确的并且是强类型的，那么需求就是合法的，也就是用例是合适的。