使用Unity注入和不使用注入创建类的实例

时间:2015-03-16 12:11:43

标签: c# .net dependency-injection inversion-of-control unity-container

我有一个API控制器,在构造函数中EmployeeService的实例用Unity实例化。

我想在EmployeeService的构造函数中注入myTest的值, 这意味着将创建Repository<Employee>的实例,_myString的内容将为“TestString”

如果有可能如何设置容器?

谢谢,

[RoutePrefix("api/employee")]
public class EmployeeController : ApiController
{
    string myTest = "TestString";
    readonly IEmployeeService _employeeService;

    public EmployeeController(IEmployeeService employeeService)
    {
        _employeeService = employeeService;
    }
}

public class EmployeeService : ServiceBase, IEmployeeService
{
    private readonly IRepository<Employee> _repoEmployee;
    private readonly string _myString;

    public EmployeeService(IRepository<Employee> repoEmployee, string myString)
    {
        _repoEmployee = repoEmployee;
        _myString = myString
    }
}

container
 .RegisterType<IRepository<Employee>, Repository<Employee>>()
 .RegisterType<IEmployeeService, EmployeeService>());

我的解决方案:

.RegisterType<IEmployeeService, EmployeeService>(
    new InjectionConstructor(
            typeof(IRepository<Employee>), 
            "MySetting"));

1 个答案:

答案 0 :(得分:1)

  

在服务类中使用来自的一些参数(键)   web.config中。这些参数在控制器中读取并发送到   服务类

控制器不应该关注从配置文件中读取数据。这样做会违反Single Responsibility Principle。这会导致可维护性问题;您正在经历的问题,因为您的设计会导致您在测试和配置DI库时遇到麻烦。

由于这些是配置值,因此在应用程序的生命周期内它们不会更改(更改配置文件将导致应用程序重新启动)。因此,控制器没有理由(一遍又一遍)读取它们。相反,您可以在启动期间读取它们并将它们注入需要该配置值的类中。

如果有多个类需要该配置值,那么您的更改很高,以至于您缺少抽象。例如,不要将连接字符串注入到许多类中,而是考虑创建一个ConnectionFactory来隐藏这些类的连接字符串,并允许根据请求创建SqlConnection

但在你的情况下,我想像这样做:

TimeSpan timeOut = TimeSpan.FromSeconds(Int32.Parse(
    ConfigurationManager.AppSettings["timeOut"]));

container.RegisterType<IRepository<Employee>, Repository<Employee>>();
container.RegisterType<IEmployeeService, EmployeeService>());
container.Register<IEmployeeService>(new InjectionFactory(c =>
    new EmployeeService(
        c.Resolve<IRepository<Employee>>(),
        timeOut)));

启动时读取配置值具有以下优点:

  • 它可以防止您的应用程序代码依赖于配置系统本身。这使您的代码更具可重用性,可测试性和可维护性。
  • 如果配置不正确,它允许应用程序在启动时快速失败。
  • 它允许您在测试套件中验证DI配置的正确性,而无需在单元测试项目中使用完全相同的配置文件。