为了加快下一个Node-API的开发速度，我正在寻找一个合适的框架。过去，我只使用快速构建我的 API。
我一直觉得有用的一种设计模式是将业务逻辑与服务中的路由处理完全分离。这些服务仅接受所需的信息(如用户 ID 或数据(，并返回解决操作结果的承诺。
通过这种方式，可以轻松地在其他路由中重用这些服务，组合它们，测试它们，或根据计划或其他事件调用它们 - 完全独立于端点调用。路由和中间件负责访问控制、错误处理和响应。
查看这些框架的文档(sailsjs，keystonejs等(我主要看到业务逻辑与各个路由紧密耦合，直接接受请求对象并处理响应。只是事后才想到，似乎有时会提供一种将"常用代码"提取到辅助函数中的方法。
我错过了什么吗？为什么这种模式似乎是 API 设计的标准？这是出于某种原因的最佳实践吗？
这可能与Node.js服务的大小较小有关。如果您来自企业背景，那么您很清楚，从长远来看，将业务逻辑与控制器代码混合在一起是行不通的。也许小项目可以无视这一点，但是一旦规模增加，你就无法避免物理定律。最好将关注点分开并保持代码库可维护。
我还要补充一点，在服务下面，最好有一个单独的层来处理与外部进程边界的通信。这样，您可以通过为集成提供适当的测试替身来隔离测试业务逻辑。以下是它在 Node 项目中如何工作的较长说明：使用 3 层架构组织 Node.js API 项目。