客户端逻辑还是服务器端逻辑?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (52)

我做了一些基于网络的项目,我遇到的大部分困难(问题,困惑)都可以通过帮助解决。但我仍然有一个重要的问题,即使在询问了一些有经验的开发人员之后:当功能可以同时使用服务器端代码和客户端脚本(JavaScript)实现时,应该首选哪一种?

一个简单的例子:

为了呈现动态html页面,我可以用服务器端代码(PHP、python)格式化页面,并使用Ajax获取格式化的页面并直接呈现它(服务器端的逻辑更多,客户端的逻辑更少)。

我还可以使用Ajax获取数据(未格式化,JSON),并使用客户端脚本对页面进行格式化,并进行更多的处理(服务器从DB或其他源获取数据,并使用JSON或XML将其返回给客户端)。客户端的逻辑更多,服务器上的逻辑更少)。

那我怎么决定哪一个更好呢?哪一个表现更好?为什么?哪一个更方便用户?

随着浏览器JS引擎的发展,JS可以在更短的时间内被解释,所以我应该更喜欢客户端脚本吗?

另一方面,随着硬件的发展,服务器性能不断提高,服务器端逻辑的成本也会降低,那么我应该更喜欢服务器端脚本吗?

客户端逻辑的优点:

  1. 更好的用户体验(更快)。
  2. 减少网络带宽(降低成本)。
  3. 增加可伸缩性(减少服务器负载)。

服务器端逻辑的优点:

  1. 安全问题。
  2. 更好的可用性和可访问性(移动设备和旧浏览器)。
  3. 更好的SEO。
  4. 易于扩展(可以添加更多服务器,但不能使浏览器更快)。

在面对特定的情况时,我们似乎需要平衡这两种方法。但怎么做?什么是最佳做法?

我将使用客户端逻辑,但在下列情况下除外:

  1. 安全关键。
  2. 特殊组(禁用JavaScript、移动设备等)。
提问于
用户回答回答于

如RiceBowl所言,永远不要信任客户端。然而,我觉得,如果你确实信任客户端,那几乎总是一个问题。如果你的应用程序值得编写,那么它就值得妥善保护。如果有人可以通过编写自己的客户端和传递你不期望的数据来破坏它,那是一件坏事。因此,你需要在服务器上进行验证。

不幸的是,如果你对服务器上的所有内容进行验证,用户的用户体验往往会很差。他们在填写表单时可能会发现,他们输入的一些内容是不正确的。这对于“Internet1.0”可能有效,但在当今的互联网上,人们的期望值更高。

这可能会让编写相当多的冗余代码,并将其保存在两个或多个地方(一些定义,例如数据层中也需要维护最大长度)。对于相当大的应用程序,我倾向于使用代码生成来解决这个问题。我个人使用UML建模工具(Sparx System‘s Enterprise Architect)来建模系统的“输入规则”。然后利用部分类(我通常在.NET中工作)来编写代码,生成验证逻辑。您可以通过将规则编码为XML格式,并从客户机和服务器层上的XML文件(输入长度、输入掩码等)中获得许多检查,从而实现类似的目标。

用户回答回答于

我倾向于喜欢服务器端的逻辑。我的理由很简单:

  1. 我不相信客户,这可能是一个真正的问题,但这是习惯性的
  2. 服务器端减少了每个事务的数量(虽然它确实增加了事务的数量)
  3. 服务器端意味着我可以相当确定发生了什么逻辑(我不需要担心客户机浏览器可用的Javascript引擎)

也许有更多更好的原因,但这些是我现在最关心的。如果我想得更多,我会把它们加起来,或者--在我之前投票给那些想出来的人。

使用客户端逻辑(使用Ajax/JSON)允许(更容易)创建API的注释。这可能是真的,但我只能同意一半(这就是为什么我还没有投赞成票)。

我的服务器端逻辑的概念是检索数据并将其组织起来;如果我做对了,逻辑就是‘控制器’(MVC中的C)。然后将其传递到“视图”。我倾向于使用控制器来获取数据,然后“视图”处理将其呈现给用户/客户端的问题。因此,我不认为客户机/服务器之间的区别必然与创建API的论点有关,基本上是:用于课程的马匹。)

我认识到我可能有一个稍微扭曲的MVC用法,所以我愿意在这一点上得到纠正。但我仍然把陈述与逻辑分开。就API而言,这种分离是其优点。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励