服务与控制器与提供程序命名约定

时间:2013-03-04 16:28:47

标签: naming-conventions

随着我职业生涯的发展,我认为命名惯例非常重要。我注意到人们抛出控制器,LibraryController,服务,LibraryService和提供者,LibraryProvider并使用它们可以互换。是否有任何具体的推理使用一个与另一个?

如果网站中有更具体的定义会很棒。

3 个答案:

答案 0 :(得分:0)

也在寻找一个比 Provider 更有意义的名称:)
并发现此实用post

答案 1 :(得分:0)

根据上下文,这些术语可以彼此同义,这就是为什么每个框架或语言创建者都可以自由地在合适的地方显式声明它们的原因...认为功能/方法/过程或过程/服务都差不多同一件事,但在不同情况下略有不同。

只需脱离正式的英语定义:

  • 提供者:提供某些东西的人或事物。
    • 即提供者通过控制某些过程来提供服务。
  • 服务:帮助某人或为某人工作的行为。
    • 即通过控制某些工作流程来提供服务。
  • 控制器:指挥或调节某物的人或物。
    • 即控制器指示要提供服务的东西。

这些定义只是列出来解释开发人员在定义框架或语言的术语时如何看待常见的英语含义;它并不总是一对一的,术语的相似性实际上为开发人员提供了一种命名非常相似但仍然略有不同的事物的方法。

因此,以AngularJS为例。在这里,开发人员决定使用控制器一词来表示“ HTML控制器”,一个服务来表示诸如“准类”之类的服务,因为它们是用New关键字实例化的,并且提供者实际上是Service和Factory的超集。也差不多。您可以使用其中的任何一个来对任何应用程序进行编程,而不会损失太多。尽管在某些情况下一个人可能会比另一个人好一些,但我个人不认为它值得额外的困惑……从本质上来说,他们都是提供商。 Angular的人可能只是将工厂,提供者和服务定义为一个单独的术语“提供者”,然后像大多数语言一样为诸如“静态”和“无效”之类的东西传入修饰符,并且可以提供完全相同的功能。这本来是我的偏爱,但是无论您多么不同意,我都学会了不与您工作的框架的惯例和术语作斗争。

答案 2 :(得分:0)

Java Spring 或Spring Boot中,您将拥有:

  • Controller =其余端点,其中包含尽可能少的逻辑。
  • Service =将包含大多数逻辑
  • Repository =只会将数据保留在数据库中并执行SQL查询。
  • 有时您会定义一个Mapper来将DTO转换为持久实体,反之亦然。或者您可以为此使用一些框架(例如MapStruct)

(AFAIK .NET从Spring复制了其所有约定。如果我错了,请纠正我。)

NodeJS 中,这些概念几乎相同。但是,术语Repository很少使用。取而代之的是,他们将其称为Provider或将其放入某些Service中。

NestJS (NodeJS框架)的命名约定受到Angular命名约定的强烈影响,这当然是一种完全不同的框架(前端),通常在Angular中,Provider实际上只是可以作为依赖项注入的东西。通常,这将是Service,但不一定。它可能是Guard甚至是ModuleModule更像是一组工具/驱动程序或连接器。

无论如何,术语Module的使用有点混乱,因为还有“ ES6模块”,这是完全不同的东西。


因此,所有这些框架都相互影响。他们几乎都同意什么是控制器和服务。具有不同含义的主要是存储库和提供程序词。这确实只是一个约定问题。如果您的框架有约定,则请遵守约定。如果没有,请自己选择一个。