业务逻辑真的属于服务器吗？

Web应用程序的典型堆栈是数据库，具有服务器端代码的服务器以及具有HTML / CSS / JavaScript的浏览器的用户。

在广泛使用AJAX之前，已将控制器作为服务器端代码的MVC删除了。服务器必须为动态网页路由答复请求（即，模板化的html解决方案，如JSP和ASP）。服务器协调对数据库的调用，并决定使用哪个动态页面来应答页面请求。所有这些的结果是，服务器最终包含了业务逻辑，即使业务逻辑与提供页面的想法没有紧密联系。

现在，我们正在向“ Web 2.0”迁移，服务器将使用JavaScript填充静态页面并更改其呈现的服务器。可以在JavaScript中。JavaScript通常实现RESTful服务，这意味着它正在指定数据库查询。

因此，服务器将承担提供实际文件和应答AJAX调用的角色。应答AJAX呼叫仅仅是会话管理和提供安全性。实际上，用户甚至应该能够看到的是应该在数据库中指定的数据。

因此，从那里开始，服务器是否应该只充当笨拙的中介角色，而这种中介只是偶尔发送电子邮件或启动Web服务之类的功能？业务逻辑可以全部存在于JavaScript中（不是秘密时）还是存在于存储过程中吗？

甚至将服务器和数据库结合在一起，或者使像SAP这样的ERP解决方案作为服务器，是否有意义？

出于安全原因，业务逻辑几乎总是必须在您控制的服务器上运行。如果用“服务器”来表示“ Web服务器”，那么我同意，它几乎不需要任何业务逻辑。但是您几乎总是需要具有业务逻辑的应用程序服务器，无论是在数据库内部还是Web服务器内部，还是由Web服务器单独调用。

在现实世界的应用程序中，Web服务器除了通过Web服务或JSON公开应用程序服务器的API之外，什么也不做。

即使在Web 2.0和AJAX之前，也确实没有将业务逻辑与ASP页面混合在一起的最佳实践。人们认为最好有一个独立的业务逻辑，并将表示逻辑的服务器部分放在ASP，JSP或其他任何形式中。因此，与Web 2.0相比，真正的变化是表示层可以完全使用javascript。我个人比较喜欢。

JavaScript通常实现RESTful服务，这意味着它正在指定数据库查询。

这是您弄错了的地方。REST 不是 CRUD。

REST公开的资源不是您的数据库记录。它们是完全托管的对象，它们根据您的业务逻辑运行。服务器收到POST或PUT时，不应仅进行验证和存储。它必须执行适合该应用程序的所有操作。

一个简单的例子：类似Twitter的应用程序在给定容器上接收POST消息作为POST消息。然后，服务器分析上下文（“您是谁？”，“这是哪个频道？”）和内容（“任何主题标签？”，文本索引等），并将所有这些内容存储在各自的队列中。可能直接向所有关注者添加参考。

除了将资源简单地添加到容器中之外，还有很多工作要做，这些都由您的业务逻辑定义。它属于服务器。

我对这种方法的担心可能是由于您对设计的误解，所以请随时击倒我。

但是，请考虑产品的可伸缩性，可维护性和安全性。

如果您的产品大量增长，则数据库将成为瓶颈，因此，尽管“性能”建议将业务逻辑放入存储过程中，但它会给数据库服务器带来额外的CPU负载，从而使服务器达到最大容量的一天出现了。与Web服务器不同，ACID数据库无法通过使用并行硬件轻松扩展。如果您的产品永远不会那么成功，那么这不是问题。

想到在运行于​​Webbrowswers上的javascript中维护业务逻辑的想法，其中不同的浏览器将要求使用不同的javascriopt，多个版本的浏览器等。为什么使这个问题比现在复杂得多？

正如Javiar所说，使用REST方法作为产品的数据库API确实是不明智的。REST接口的好处是其他人会想到使用和查询REST接口的不同方法。但是，这是公共岗位业务逻辑资源，而不是低级表记录资源。通过HTTP api提供此类低级数据查询的想法听起来像一场安全噩梦。

尽管对此有很多流派，但肯定没有一种方法可以普遍地称为“正确的方法”，而所有其他方法都可以普遍地称为“错误的方法”，但是有很多原因可以在服务器端隔离业务逻辑。 ，并通过RESTful服务访问这些对象和服务。

简短的答案是，它主要是关于风险管理，绩效监控和改进。

详细：

数字1最重要的原因是安全性。永远不要信任客户端向服务器提交除垃圾以外的任何内容，并且通过保留服务器方面的安全性，您可以隔离恶意用户损坏系统的潜在风险。请记住，Javascript完全是客户端，并且可以轻松更改，因此您不能信任输出。

第二个原因是关注点分离。您的JavaScript程序员可能不是安全专家，而您的安全专家也不擅长Javascript。通过将业务逻辑与表示逻辑隔离开来，您可以避免遇到这些问题，因为将不允许javascript访问超出其权限级别的资源，并且会遇到错误，这些错误的处理属于Script Programmer的范围。同样，安全人员也不会调试Javascript以查看如何维护安全性。

第三个原因是性能。业务逻辑可能会要求服务器和数据库资源。通过使该逻辑与UI元素隔离，您便可以仅扩展应用程序的那部分，从而更轻松地解决瓶颈。此外，如果在服务器上执行业务流程，则隔离哪个业务流程正在加载系统或数据库后端要容易得多。

必然的结果是，经常有几个业务流程将使用相同的数据，因此您可以在服务器端实现缓存以减少总体系统负载，而这可能/不可能确保客户端代码访问权限。

最后，我建议为了维持ACID标准，业务逻辑确实确实需要在服务器上。我记得在维护一个在Web浏览器中运行的计费产品，该数据库仅与服务器建立数据库连接。如果每天的帐单（一天下来可能需要一个小时或更长时间！），例如由于浏览器关闭或崩溃而中断，则可能需要几个小时才能整理出数据库造成的混乱情况处于不一致状态。请记住，这也涉及信用卡，因此帐单记录也必须对照处理器进行检查！

服务器端业务逻辑对于确保ACID更新来说很简单，因为在应用程序或数据库级别，都有用于任何语言的任何框架来维护事务。如果要通过Web客户端进行多次更新来执行此操作，则某些时候状态会不一致，这很可能会影响您的应用程序。

尽管将RESTful服务仅视为访问数据库的一种方式可能很诱人，但您不应该陷入这个陷阱，因为这是灾难的好方法。通过RESTful服务公开的对象模型可以与数据库相关，但实际上应该封装您的业务逻辑，而不仅仅是将其用作CRUD引擎。