Как реализовать IDependencyResolver в приложении уровня N уровня?

Question

У меня есть трехслойное приложение. Каждая из частей имеет зависимости от другой части моего решения. Я использовал для реализации IDependencyResolver внутри проекта MVC. Это неправильный путь, потому что это приводит к нарушению архитектурных правил разделения слоев. Мой проект MVC имел ссылку на слой DAL. Это плохая практика кодирования. Я знаю, что я могу создать отдельный проект библиотеки классов. Он будет иметь ссылки на любые другие проекты моего решения. Он разрешит все зависимости. Я слышал, что это не лучший способ. Существует лучший способ. Каждый проект моего решения должен решить, что он владеет зависимостями. Я не понимаю, как собрать все это вместе. Поэтому я нашел эту полезную статью: Dependency Injection Best Practices in an N-tier Modular Application, но это кажется слишком сложным и сложным. Есть ли другой способ? У меня есть аналогичная структура решения. UserRepository возвращает запрашиваемого пользователя.

public interface IUserRepository 
    { 
     IEnumerable<UserEntity> GetAll(); 
    } 

    public class UserRepository : IUserRepository 
    { 
     public IEnumerable<UserEntity> GetAll() 
     { 
      // some code 
     } 
    } 

UserService может иметь несколько разных зависимостей.

public interface IUserService 
    { 
     IEnumerable<UserModel> GetAll(); 
    } 

    public class UserService : IUserService 
    { 
     private readonly IUserRepository userRepository; 
     private readonly ISecondRepository secondRepository; 
     private readonly IThirdRepository thirdRepository; 

     public UserService(IUserRepository userRepository, ISecondRepository secondRepository, IThirdRepository thirdRepository) 
     { 
      this.userRepository = userRepository; 
      this.secondRepository = secondRepository; 
      this.thirdRepository = thirdRepository; 
     } 

     public IEnumerable<UserModel> GetAll() 
     { 
      // some code 
     } 
    } 

И наконец UserController конструктор мощь имеет много различных зависимостей.

Мой вопрос в том, что является правильным и самым простым способом разрешения этих зависимостей, не допуская нарушения архитектурных правил?

Answer 1

Как вы сказали, что вы можете создать дополнительный слой, который будет сочинить зависимости, это называется состав корня Check this SO question. В вашем случае корнем композиции является проект MVC. С моей точки зрения ссылка на DAL - это не плохая практика.Если мы говорим о зависимостях, мы должны нарисовать линию. Для меня, когда мы говорим о зависимостях, не так важна ссылка dll, а тип (интерфейс или бетон), который используется. Как вы знаете, DI зависит от абстракции, где она имеет фактическое значение. Таким образом, ваш код все еще в порядке, если вы зависите только от интерфейсов в DAL.

В практике я использовал дополнительный проект в качестве корня композиции, когда зависимости dll стали слишком сложными.

О вашем вопросе О том, как слои должны разрешать свои зависимости. Я не уверен, что это то, что вы имели в виду, но в DDD есть практика, когда ваш BLL определяет интерфейсы инфраструктуры (например, репозитории) в своем слое. Таким образом, граф зависимостей почитается. Теперь уровень инфраструктуры (DAL) определяет только конкретную реализацию интерфейсов, предоставляемых BLL, и снова в корне композиции все подключено.

Первый подход, где уровень инфраструктуры определяет интерфейс, а реализация имеет преимущество быть свободной от зависимостей, которая может использоваться для повторного использования в разных проектах. Но имейте в виду, что при работе в большом домене это иногда может привести к непритязательному коду.

Второй подход Будучи DDD, самое важное - это домен, поэтому все работает для домена. По моему опыту хорошо структурированные слои вокруг домена - лучший вариант. Этот apporach делает ваш код более явным о проблемах, которые вы решаете для домена. Я не знаю, если я сам выражу свое я.

В качестве окончательного примечания я предлагаю вам подход DDD, если вы используете это как опыт обучения. Изучение чего-то нового - лучший вариант.

Я не самый опытный человек в этой области. Я программист около 3 лет, и я работал в основном на проектах среднего размера, поэтому мое мнение не является твердым;]

Answer 2

Поскольку я читал эту статью, я делал все свои проекты, используя этот метод. Очень рекомендуется поэтапно понимать «корень композиции».

http://www.dotnetcurry.com/aspnet-mvc/829/dependency-injection-ninject-aspnet-mvc