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

Question

已结束。此问题正在寻求书籍、工具、软件库等的推荐。它不满足 Stack Overflow guidelines 。目前不接受答案。

---

我们不允许提出寻求书籍、工具、软件库等推荐的问题。您可以编辑问题，以便用事实和引文来回答。

已关闭 6 年前。

Improve this 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 具有基于原型(prototype)的继承，但很多 OO 模式)只是不能很好地翻译成 Javascript)。

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

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

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

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