我有一个带有3 dll的应用程序（web.dll，businesslogic.dll和services.dll）。 Web应用程序实例化使用服务的业务逻辑对象。所有服务都是＆＃34;隐藏＆＃34;在接口后面，我使用autofac将实现注入业务逻辑对象。没什么好看的。
我试图通过将我的服务的接口公开来为我的应用创建更好的封装，但是通过将其设置为内部来隐藏我的类型的实现。使用Autofac自动注册，除非构造函数具有某些值类型参数（如连接字符串），否则它可以正常工作。我有3个替代品，各有利弊，所以我想知道哪一个会被认为是最好的：
用接口替换我的所有值参数（例如：IMyServiceConfigurations），这很好但是创建了很多1个属性接口和实现，它们混淆了一些构造函数
将autofac模块中的注册放入我的服务dll中。这样做，我依赖于我不太喜欢的服务dll中的Autofac。我更喜欢只有应用程序的根（Web应用程序）才能依赖容器
使用NamedParameter或TypedParameter但是为此，应用程序的根需要知道将要使用的构造函数（以及实现），以便以另一种方式破坏封装。
关于如何在不将服务dll泄露到服务dll之外的任何想法或意见。
感谢。
答案 0 :(得分：1)
我试图通过公开我的服务的接口来创建一个更好的应用程序封装，但是通过使其内部隐藏我的类型的实现
在考虑封装的情况下，使内部类不会改变任何内容。由于您的组件依赖于抽象，因此从消费者的角度来看，封装没有区别。他们仍然不知道实施的存在。当您将实现移动到消费者不依赖的不同程序集时，这可能会被夸大。通过这种方式，实现可以保持公开，而消费者无法直接使用它。
除此之外，即使实现是公共的，它通常仍会保护其不变量，方法是将除了实现的接口公开的部分之外的所有内容都设置为内部。这意味着它仍在应用封装，即使它是公开的。
在业务线应用程序中，通常通过内部实现来获得任何收益。您的应用程序之外的任何人都不会尝试使用这些类型。但是，这些实现有两个消费者。这些消费者是您的单元测试和应用程序composition root。对于他们两个人而言，如果你把它们作为内部工作，那只会让你的工作更加困难。
重新考虑将这些类型公之于众。