我应该尽量减少控制器中的接口数量吗?
在下面的片段中,我的控制器采用三个接口。这些是通过 Ninject 连接的。好吧,一切都很好,绝对是朝着正确方向迈出的一步。我的问题是这样的?
1.) 将 3 个接口包装成一个接口并以这种方式实现,从而减少传递给控制器的参数数量会更好吗? 2.)别管它,它有效吗?
我一直在寻找从一切事物中抽象出来的方法。 想法?
public class RegistrationController : Controller
{
private readonly ICategoriesService _categoriesService;
private readonly IAuthenticationService _authenticationService;
private readonly IRegistrationService _registrationService;
// Ctor
public RegistrationController(ICategoriesService categoriesService,
IAuthenticationService authenticationService,
IRegistrationService registrationService)
{
_categoriesService = categoriesService;
_authenticationService = authenticationService;
_registrationService = registrationService;
}
}
In the below snip I have my controller which takes three interfaces. These are wired up via Ninject. Ok all great, definately a step in the right direction. My questions are this?
1.) Would it be better to wrap the 3 interfaces up in to one interface and a implement that way, thus reducing the amount of params passed to the ctor of the controller?
2.) Leave it alone, it is working?
I am always looking for ways to abstract the hell out of everything..
Thoughts?
public class RegistrationController : Controller
{
private readonly ICategoriesService _categoriesService;
private readonly IAuthenticationService _authenticationService;
private readonly IRegistrationService _registrationService;
// Ctor
public RegistrationController(ICategoriesService categoriesService,
IAuthenticationService authenticationService,
IRegistrationService registrationService)
{
_categoriesService = categoriesService;
_authenticationService = authenticationService;
_registrationService = registrationService;
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
拥有一个巨大的接口(或一个巨大的类,这是实现一个巨大的接口所需要的),因为它“方便”,被广泛认为是反模式。根据您当前接口的名称,它们似乎围绕它们提供的操作类型进行了很好的逻辑结构,我建议您保持这种方式(这也提供了更高的灵活性,因为可能有其他地方您只需要需要一些接口)。
顺便说一句:如果您有适当的单元测试和集成测试,那么“别管它,它正在工作”是永远不需要的短语。 ;-)
Having a huge interface (or a huge class, which is what you'll need in order to implement a huge interface) because it is "convenient" is widely considered an antipattern. Based on the names of your current interfaces, they seem to be nicely and logically structured around what kind of operations they provide, and I suggest that you keep them that way (this also gives higher flexibility, since there may be other places where you only need some of the interfaces).
By the way: If you have proper unit tests and integration tests, "leave it alone, it's working" is a phrase that is never needed. ;-)