如何在 N 层应用程序中实现 IDependencyResolver？

Question

我有一个三层的应用程序。每个部分都依赖于我的解决方案的另一部分。我曾经在 MVC 项目中实现IDependencyResolver。这是一种错误的方式，因为它会导致违反层分离的架构规则。我的 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，最​​重要的是域，所以一切都适用于域。根据我的经验，在域周围拥有结构良好的层是最好的选择。这种方法使您的代码更明确地说明您为域解决的问题。 我不知道我是否正确地表达了自己。

作为最后一点，如果仅将其用作学习经验，我会建议您使用 DDD 方法。学习新东西是最好的选择。

我不是该领域最有经验的人。 我做了大约 3 年的程序员，主要从事中型项目，所以我的意见并不可靠；]