依赖注入:我应该完全隐藏实现并依赖于容器，还是保持我的实现和构造函数是公共的?
本文关键字：实现 我的 构造函数 我应该 注入 隐藏 依赖 依赖于 | 更新日期: 2023-09-27 18:15:28
我有一个应用程序与3个dll (web.dll, businesslogic.dll和services.dll)。web应用实例化使用服务的业务逻辑对象。所有服务都"隐藏"在接口后面，我使用autoface将这些实现注入到业务逻辑对象中。
我试图为我的应用程序创建一个更好的封装，通过使我的服务的接口公开，但隐藏我的类型的实现通过使他们内部。使用Autofac自动注册，除非构造函数有一些值类型参数(如连接字符串)，否则它工作得很好。我有三个选择，每个都有利弊，所以我想知道哪一个会被认为是最好的:
-
将我所有的值参数替换为接口(例如:imyservicecconfigurations)，它工作得很好，但创建了很多1属性接口和实现，这些接口和实现混淆了构造器
-
将autofac模块中的注册放入我的服务dll中。这样做，我在服务dll中依赖于Autofac，这是我不太喜欢的。我更喜欢只有应用程序的根(web应用程序)依赖于容器
-
使用NamedParameter或TypedParameter，但要这样做，应用程序的根需要知道将要使用的构造函数(和实现)，所以封装以另一种方式被打破。
关于如何在不泄漏服务dll外部实现的情况下实现这一点，有什么想法或评论吗?
谢谢。
我试图创建一个更好的封装为我的应用程序通过使我的服务的接口公开，但隐藏我的类型的实现通过使他们内部
考虑到封装，使类内部化不会改变任何东西。由于您的组件依赖于抽象，因此从使用者的角度来看，封装没有区别。他们仍然不知道实现的存在。当您将实现移动到使用者不依赖的不同程序集时，这一点可能会被夸大。通过这种方式，实现可以保持公共，而消费者不能直接使用它。
除此之外，即使实现是公共的，它通常仍然会通过将除由其实现的接口公开的部分外的所有内容都放在内部来保护其不变量。这意味着它仍然在应用封装，即使它是公共的。在业务线应用程序中，通过内部实现通常一无所获。应用程序之外没有人会尝试使用这些类型。不过，这些实现有两个消费者。这些消费者是您的单元测试和应用程序的组合根。对于这两种人来说，如果你把它们放在内部，只会让你的工作更加困难。