业务逻辑:客户端与服务器端

Question

假设3-5年前(或多或少)服务器端的n层应用程序--以及一些用于UI的javascript/html/CSS是web开发的基本方法。

现在我们可以看到，传统的web开发模式发生了很大的变化。每天，我看到越来越多的应用程序没有服务器端的传统方式。他们只消耗一些服务(数据服务，服务，等等)。但是业务逻辑放在客户端。此外，已经有许多javascript框架根据这样的模型(角、骨干等)为简化开发而创建。

与传统方法相比，新模式的主要优缺点是什么？

Answer 1

这种方法有以下几个优点：

• 响应性，因为业务逻辑在胖客户机中，所以您不需要等待每次交互在网络上的往返。
• 复杂--在客户端拥有所有的控制和更高层次的逻辑，可以实现丰富的用户界面(例如，本站点或gmail)，如果每次交互都需要往返到服务器的话，这是不可能的。
• 可伸缩性，所有这些处理都发生在您的设备上，使用您的电力。如果您有大量用户，则服务器端处理中的节省是很重要的。

不过，也有一些不利因素。

• 缺乏对客户端环境的控制。您不知道哪个浏览器在哪个操作系统上，或者您的客户端将拥有什么样的屏幕大小和处理能力。您的应用程序可能不适用于每个客户端。
• 不平衡的反应。大型客户端库需要不时下载和升级，这将是比较慢的，一旦下载响应是闪电般的快，用户，一般更喜欢一致的响应时间，即使它是稍慢一点。
• Javascript --要么喜欢它，要么讨厌它--你一直把它作为你的主要开发语言。您的代码公开了，这是一些公司不喜欢的(也许他们对代码质量感到尴尬？)。
• 安全性--您的服务器端代码现在基本上只是数据库服务，其API对研究Javascript的任何人开放，因此您需要格外小心地保护这些服务。

Answer 2

我想我们谈的是两种逻辑：

应用逻辑和业务逻辑。

应用程序逻辑包含用例。业务逻辑包含业务规则。应用程序逻辑(和表示逻辑)可以在客户端实现.业务逻辑仅在服务器端。

Answer 3

除了@James说的话，如果您正在使用共享数据库表的系统，您希望避免在服务器和您选择使用的每一种客户端上重复业务规则。在某些情况下，您必须进行验证，但如果可能的话，不应该重复其他业务规则。试图在不同语言中复制相同的规则很容易出错。此外，有时您需要提取几个数据片段，并将这些数据拉到客户端以执行验证。这有悖于反应能力。

INMO，当响应性不是一个关键问题时，将关注点分离视为设计中的一个优先事项。

我避免提出的一个问题是“你对那些让JS关闭的客户做什么？”