Mic*_*ael 6 naming-conventions
随着我职业生涯的成长，我认为命名约定非常重要。我注意到人们会乱扔控制器、LibraryController服务、LibraryService提供者，LibraryProvider并且在某种程度上可以互换使用它们。使用其中一种与另一种有什么具体的理由吗？
如果有网站有更具体的定义那就太好了。
在Java Spring、 Spring Boot 和.NET中，您将拥有：
Repository：将数据持久化到数据库并执行SQL查询。Service：包含大部分业务逻辑Controller：定义REST端点，其中包含尽可能少的逻辑。从概念上讲，这意味着“内容”（功能）与“方式”（技术）尽可能分开。这些服务试图保持技术中立。相比之下，控制器只想定义外部通信合同。最后，存储库只是为了方便对数据库的访问。
以这种方式组织代码可以使业务逻辑保持简短、简洁和可维护。不幸的是，将它们分开并不总是那么容易。例如，用装饰器/注释形式的元数据来污染或丰富您的对象是很诱人的。（例如数据库列名称和数据类型）。
一些开发人员没有看到这有什么坏处，并侥幸逃脱。其他人将其对象严格分开并定义多组对象。
拥有多个对象意味着您需要Mappers将一种类型的对象转换为另一种类型。有些框架可以为你做到这一点（例如MapStruct）。
人们很容易声称严格总是一件好事，但它会减慢你的速度。取得平衡就可以了。
在Node.js中，控制器和服务的概念是相同的。然而，这个术语Repository并不经常使用。相反，他们会称之为“a” Provider，或者有时他们只是将其概括Repositories为“a” Service。
NestJS对此有更强烈的看法（这可能是一件好事）。NestJS （一个 Node.js 框架）的命名约定深受 Angular 命名约定的影响，Angular 当然是一种完全不同类型的框架（前端）。
（为了完整起见，在 Angular 中， aProvider实际上只是可以作为依赖项注入的东西。大多数提供者都是Services，但不一定。（它可能是 aGuard甚至是Module。 AModule更像是一组工具/驱动程序或一个连接器。）
PS：无论如何，这个术语的用法Module有点令人困惑，因为还有“ES6模块”，这是完全不同的东西。）
ES6 和更现代版本的 javascript（包括 typescript）在（解）构造对象方面非常强大。这使得映射器变得不必要。
话虽如此，现在大多数 Node.js 和 Angular 开发人员更喜欢使用 TypeScript，在定义类型方面，它比 Java 或 C# 具有更多功能。
因此，所有这些框架都在相互影响。他们几乎都同意什么是控制器和服务。主要是“存储库”和“提供者”这两个词具有不同的含义。这实际上只是一个约定问题。如果您的框架有约定，请遵守该约定。如果没有，那就自己选一个。
根据上下文，这些术语可以彼此同义，这就是为什么每个框架或语言创建者都可以自由地显式声明它们，因为他们认为合适......想想函数/方法/过程或流程/服务，几乎都是一样的东西但在不同的上下文中略有差异。
只是脱离正式的英语定义：
列出这些定义只是为了解释开发人员在定义框架或语言的术语时如何看待常见的英语含义；它并不总是一一对应的，术语上的相似性实际上为开发人员提供了一种命名非常相似但仍然略有不同的事物的方法。
以 AngularJS 为例。在这里，开发人员决定使用术语“控制器”来表示“HTML 控制器”，使用“服务”来表示“准类”之类的东西，因为它们是使用 New 关键字实例化的，而提供程序实际上是服务和工厂的超集，它是也类似。您确实可以使用它们中的任何一个来编写任何应用程序，并且实际上不会丢失任何东西；虽然在某些情况下一个可能比另一个好一点，但我个人认为不值得额外的混乱......本质上他们都是提供者。Angular 的人们可以将工厂、提供者和服务定义为一个术语“提供者”，然后像大多数语言一样传入“静态”和“无效”等修饰符，并且可以提供完全相同的功能；这是我的偏好，但是我学会了不要违背你所使用的框架的惯例和术语，无论你多么强烈地不同意。