1 
public List<IBusinessObject> RetrieveAllBusinessObjects()
{
    var businessObjectType= typeof(IBusinessObject);

    List<Type> implementationsOfBusinessObject = AppDomain.CurrentDomain.GetAssemblies()
         .SelectMany(s => s.GetTypes())
         .Where(businessObjectType.IsAssignableFrom).ToList();

    return implementationsOfBusinessObject.Select(t =>(IBusinessObject)Activator.CreateInstance(t)).ToList();
}

堆栈溢出的用户建议我检查依赖注入作为上述代码段的解决方法。这样做有什么好处？

只是对场景的简要概述：

我们的数据库几乎没有存储过程，因此我们已经开始为更复杂的表实现 C# 业务对象。由于我们希望尽快切换数据库，这似乎是最好的选择。所有业务对象都必须在运行时使用反射加载以帮助管理它们。所有这些业务对象都实现了接口 IBusinessObject。

使用依赖注入的建议来自这个问题

编辑：

  1. RetrieveAllBusinessObjects 方法位于接口后面的类中，因此可直接测试

  2. 如果有任何改变，我们会使用 AutoFac。我们不使用单独的配置文件。

-

4

2 回答 2

1

而不是使用上面的代码，您只需使用在应用程序的配置文件中配置的 DI，但有时您可以在方法中装饰属性或参数，然后将其自动注入（通过以编程方式设置的映射或通过配置）当请求访问该对象或将在参数中调用的方法中调用它时。

它还使它更具可测试性，因为您可以创建实现接口的不同具体类型，然后不必重新编译代码，您只需通过配置文件轻弹映射，中提琴......一切正常。

于 2013-10-13T21:36:42.750 回答
0

DI 会完成上述操作，而无需您编写代码来执行此操作，因此您引入错误的机会更少。

DI 为您带来更多好处，例如

  • 使测试单个代码单元变得更容易。可以模拟依赖关系，因此您可以限制正在测试的代码
  • 易于理解代码中的依赖关系。依赖项通常在某些地方注入，通常是构造函数。
  • 链接到上面的 1/，因为您现在应该在代码之间定义接口，当您的需求发生变化并且需要重写组件时，您可以更有信心地这样做，因为它可以与您现有的代码库一起使用。

其他人可能可以更好地描述其他好处，但您需要根据自己的需要评估这些好处。

于 2013-10-15T12:01:12.847 回答