如何在自定义成员资格提供程序中实例化服务层类答案

【问题标题】：How to instantiate Service Layer class in a Custom Membership provider如何在自定义成员资格提供程序中实例化服务层类
【发布时间】：2011-12-01 13:04:22
【问题描述】：

我正在设计一个包含以下层的应用程序

数据层（在 EF 4.1 之上具有通用存储库）
服务层 - 所有业务逻辑都在这里
ASP.NET MVC 3 网站和 ServiceStack.NET Web 服务

我正在尝试实现一个自定义会员提供程序来利用我的服务/存储库

虽然我最初是从提供程序中调用服务层方法，但当然，我不能使用 DI（通过 Ninject），因为成员资格由框架处理，并阻止我使用构造函数注入。

我已尝试通过以下方式在提供程序的初始化方法中实例化我的 UserService 类的实例：

userService = (UserService)Activator.CreateInstance(typeof(UserService));

但鉴于用户服务依赖于 Ninject 注入的存储库，这不起作用，因为存储库永远不会被注入。

我在这里缺少什么？解决此问题的最简单方法是什么？我应该从一个完全不同的角度来看这个吗？

编辑：这是我要求的用户服务

public class UserService : IUserService
{
    private readonly IUserRepository userRepository;
    private readonly IUnitOfWork unitOfWork;

    public UserService(IUserRepository userRepository, IUnitOfWork unitOfWork)
    {
        this.userRepository = userRepository;
        this.unitOfWork = unitOfWork;
    }


    //methods(AddUser, etc.)...

}

【问题讨论】：

DI 只存在于你的顶层吧？您不需要在其余层中使用 DI。在顶部，我指的是您的 MVC 应用程序。
我实际上是在所有层中使用 DI 来注入层之间的依赖关系。服务层类依赖于存储库，因此服务层围绕接口构建，并注入具体的存储库。 DI 只设置在 global.asax 的顶层，如果这就是你的意思？我的方法是不好的做法吗？
实际上，我的整个架构都是根据这个示例建模的：efmvc.codeplex.com 只有我使用的是 Ninject 而不是 Unity
架构听起来不错，我只是想检查一下您只是在 MVC 层而不是在其他层中执行实际的注入部分（使用 DI 框架）。
请给我们看看你的UserService的代码。

标签： c# .net asp.net asp.net-mvc-3 asp.net-membership

【解决方案1】：

如果您的核心问题是测试并让您的 DI 工作，那么一种选择是外观成员位并在外观之外创建一个接口。然后，您可以设置单元测试，甚至可以使用某种类型的 IoC 容器 (DI) 库。

【讨论】：

我在一些旧代码中可能有一个，但我不确定我是否还有它。我会看的，但这将是这个周末。我确实有其他类型的外墙的例子，如果这个概念足以让我们滚动的话。