Как создать экземпляр класса уровня обслуживания в пользовательском поставщике членства

#c# #.net #asp.net #asp.net-mvc-3 #asp.net-membership

#c# #.net #asp.net #asp.net-mvc-3 #asp.net-членство

Вопрос:

Я разрабатываю приложение со следующими уровнями

Уровень данных (с общим репозиторием поверх EF 4.1)
Уровень обслуживания — вся бизнес-логика идет сюда
ASP.NET Веб-сайт MVC 3 и ServiceStack.СЕТЕВЫЕ веб-службы

Я пытаюсь реализовать пользовательский поставщик членства для использования моих сервисов / репозиториев

Моим первоначальным решением было вызвать методы уровня обслуживания из поставщика, но, конечно, я не могу использовать DI (через Ninject), поскольку членство обрабатывается фреймворком и не позволяет мне использовать внедрение конструктора.

Я попытался создать экземпляр моего класса UserService в методе initialize в поставщике через:

 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.)...

}

1. DI существует только на вашем верхнем уровне, верно? Вам не нужен DI в остальных ваших слоях. По началу я ссылаюсь на ваше приложение MVC.

2. На самом деле я использую DI во всех слоях для введения зависимостей между слоями. Классы уровня обслуживания зависят от репозиториев, поэтому уровни обслуживания строятся вокруг интерфейсов, а конкретные репозитории вводятся. DI настраивается только на верхнем уровне в global.asax, если это то, что вы имеете в виду? Является ли мой метод плохой практикой?

3. На самом деле, вся моя архитектура смоделирована после этого примера: efmvc.codeplex.com Только я использую Ninject вместо Unity

4. Архитектура звучит нормально, я просто хотел проверить, что вы выполняете только фактическую часть внедрения (используя DI framework) на своем уровне MVC, а не на других уровнях.

5. Не могли бы вы показать нам код вашего пользовательского сервиса, пожалуйста.

Ответ №1:

Если ваша основная проблема заключается в тестировании и обеспечении работы вашего DI, то одним из вариантов является фасад битов членства и создание интерфейса вне фасада. Затем вы можете настроить модульные тесты и даже использовать некоторый тип библиотеки контейнеров IoC (DI).

1. Возможно, у меня есть один в каком-то старом коде, который я сделал, но я не уверен, что он у меня все еще есть. Я посмотрю, но это будет в эти выходные. Однако у меня есть примеры других типов фасадов, если концепции достаточно для запуска.