.net 在使用外部框架时,如何避免过度开放类?

.net 在使用外部框架时,如何避免过度开放类?,.net,asp.net-mvc,asp.net-web-api,class-visibility,.net,Asp.net Mvc,Asp.net Web Api,Class Visibility,我们有很多MVC和WebAPI项目,它们使用依赖项注入从两个框架中的控制器访问服务类和其他依赖项。我遇到的问题是,我想让所有服务都特定于每个项目internal,但我做不到,因为两个框架上的控制器类都需要是公共的,如果我试图使用构造函数注入接收内部类型的参数实例,这会导致编译错误 这不止一次地折磨着我。几乎所有调用代码的框架都会出现这种情况,无论是WebAPI、MVC甚至WebForms等web框架,还是测试等其他类型的项目,测试类也需要公开 一般来说,我对面向对象的理解是,您希望有一个尽可能封

我们有很多MVC和WebAPI项目,它们使用依赖项注入从两个框架中的控制器访问服务类和其他依赖项。我遇到的问题是,我想让所有服务都特定于每个项目
internal
,但我做不到,因为两个框架上的控制器类都需要是公共的,如果我试图使用构造函数注入接收内部类型的参数实例,这会导致编译错误

这不止一次地折磨着我。几乎所有调用代码的框架都会出现这种情况,无论是WebAPI、MVC甚至WebForms等web框架,还是测试等其他类型的项目,测试类也需要公开

一般来说,我对面向对象的理解是,您希望有一个尽可能封闭的范围,这样东西就只能访问它们需要处理的一组最小的特性。我发现这通常是一种非常好的方法,因为它将其他内容对每个类的影响降至最低,并导致更清晰、更容易发现代码

我的服务课就是这样。它们被创建为仅由同一程序集中的控制器使用,而不由其他任何人使用。由于必须将它们标记为public,我无缘无故地将它们暴露给外部调用者,并且这样做会丢失很多重要的编译时信息,例如,如果没有人从内部类调用某个方法,FxCop会警告我,但不能推断如果该类标记为public,因为项目(甚至解决方案)之外的其他人可能正在使用该类型并调用该方法

这显然也扩展到了接口。正如我所说的,我们正在使用依赖项注入(使用Unity),在该场景中,通常每个服务类都有一个接口。即使我可以将实现本身标记为内部,但需要将接口公开仍然不理想


是否有某种模式允许我清晰地定义内部类和接口,但仍然与外部框架一起工作,这些框架需要我的面向外部的类是公共的,以便它们可以调用我?一般来说,我应该如何确保代码的作用域尽可能紧密?

我建议使用facade模式,这里讨论:


我知道façade模式,但它根本无法解决我提到的问题,它只会将问题转移到façade接口和实现。是的,它会将问题转移到facade。我假设您可以在facade中提供服务类功能的有限子集,从而限制任何外部调用方的访问。使用以下指令只允许外部程序集访问您的内部组件怎么样:
[assembly:InternalsVisibleTo(“此处的程序集名称”)]
我在这里看到了这一点:问题是在这种情况下,我需要“授予权限”的程序集不是我的。你看,这就是为什么我在标题中说使用外部框架。发生的情况是MVC需要创建路由和控制器,但是如果我将控制器标记为
internal
,那么MVC引擎不会将其识别为有效的控制器,我会得到404响应。其他框架也有同样的情况:在WebForms中,页面类需要是公共的,而MSTest也要求测试类是公共的。对后两者的影响不太明显,因为它们不支持依赖注入。事实上,我已经在这样做了。控制器类是唯一需要服务的类,它们位于同一程序集上。问题是我需要将这些控制器标记为
public
,因为外部框架需要它。这反过来又使得我无法将我的服务类标记为
internal
,因为在C#中通过其构造函数使公共类依赖于内部类是非法的。我希望保留构造函数依赖项方案,因为它是执行依赖项注入的最佳位置。