C#.net 开发人员的 Node.js 最佳实践

Question

我是 Node.js 新手，有 C#.net 背景。在 .net 中编码时，我习惯于使用多种设计模式来组织我的代码、服务层、存储库等。当我需要添加跨越多个模型的逻辑时，我也可以使用服务来实现这一点。转向 Node.js 并查看示例和示例代码等。我没有看到大量使用服务层、存储库等。以下推荐的做法是什么：

1. 代码组织和结构，特别是对于业务逻辑丰富的应用程序？

2. 如何处理跨越多个模型的逻辑？

3. 有哪些好的教程和示例代码网站可以展示一些好的项目和代码结构，其中包含项目 (1 和 (2？

.net 附带了很多推荐的方法、实践、模式和编码结构技术，这些实际上都是非常好的推荐。像www.asp.net等网站为这些推荐提供了相当好的文章等。

我无法找到一致的方法来查看 Node.js 示例。

Answer 1

和您一样，我从 C#/.NET 转向 Node.js，发现我认为在 C# 中很好的实践在 Node.js 中用处不大。

领域驱动设计 (DDD) 在 Node.js 设置中并不经常讨论，因为 DDD 通常与面向对象设计相关，而 Javascript 不是 OO 语言（尽管 Javascript 具有基于原型的继承，但许多 OO 模式根本不具备这种能力）不能很好地翻译成 JavaScript）。

相反，我们看到了更多的微服务架构，通过这种架构，我们将大型领域分解为更小的、解耦的服务，这些服务可以很好地执行一项业务功能。Node.js 非常适合此类轻量级 HTTP 服务。

我发现的有趣的事情是，在尝试了 DDD 上的微服务方法之后，我实际上发现它更容易实现，并且更容易沿着适当的路线保持事物的解耦。事实上，当我回到 C# 时，我发现自己也在那里应用了微服务方法。

就模式而言，抽象出持久性仍然是一个非常好的主意 - 类似于存储库模式的东西可以很好地从 OO 转换为 Node.js。至于将业务逻辑放在哪里，我发现有时需要在存储库上有一个“服务”或“应用程序”层，以便我可以访问多个存储库来编译复杂的响应。有时您不需要额外的抽象，因此只需将其放在需要的地方即可 - 不要过于热衷于业务逻辑层 - 这是 N 层思维，它会导致编写大量不必要的代码。当抽象变得有用时添加它们，而不是作为占位符以防万一需要 - 这是一种过早的优化。

当我们需要真正高级的业务逻辑时，我们可能需要协调多个微服务的操作。Node.js 也是您的朋友 - 您可以编写轻量级编排服务来使用 ESB 上的消息并对它们做出反应。