客户端逻辑还是服务器端逻辑? [英] Client-side logic OR Server-side logic?

问题描述

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

一个简单的例子:

要呈现动态 html 页面，我可以在服务器端代码(PHP、python)中格式化页面并使用 Ajax 获取格式化页面并直接呈现(服务器端逻辑更多，客户端更少).

我还可以使用 Ajax 来获取数据(未格式化，JSON)并使用客户端脚本来格式化页面并通过更多处理来呈现它(服务器从数据库或其他来源获取数据，然后返回它)使用 JSON 或 XML 发送到客户端.客户端的逻辑更多，服务器的逻辑更少).

那么我该如何决定哪个更好呢?哪一种性能更好?为什么?哪个更人性化?

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

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

有了答案，我想做一个简短的总结.

客户端逻辑的优点:

1. 更好的用户体验(更快).
2. 更少的网络带宽(更低的成本).
3. 提高可扩展性(减少服务器负载).

服务器端逻辑的优点:

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

似乎我们在面对特定场景时需要平衡这两种方法.但是如何?最佳做法是什么?

除以下情况外，我将使用客户端逻辑:

1. 安全至关重要.
2. 特殊群体(禁用 JavaScript、移动设备等).

解决方案

在很多情况下，恐怕最好的答案是两者.

正如 Ricebowl 所说，永远不要相信客户.但是，我觉得如果您确实信任客户，这几乎总是一个问题.如果您的应用程序值得编写，则值得妥善保护.如果有人可以通过编写自己的客户端并传递您不期望的数据来破坏它，那是一件坏事.因此，您需要在服务器上进行验证.

不幸的是，如果您验证服务器上的所有内容，通常会给用户带来糟糕的用户体验.他们可能会填写表格，却发现他们输入的一些内容不正确.这可能适用于互联网 1.0"，但人们对当今互联网的期望更高.

这可能会让您编写相当多的冗余代码，并将其维护在两个或多个位置(一些定义，例如最大长度也需要在数据层中维护).对于相当大的应用程序，我倾向于使用代码生成来解决这个问题.我个人使用 UML 建模工具(Sparx System 的 Enterprise Architect)对系统的输入规则"进行建模，然后使用部分类(我通常在 .NET 中工作)来代码生成验证逻辑.您可以通过以 XML 等格式对规则进行编码并在客户端和服务器层从该 XML 文件(输入长度​​、输入掩码等)中派生出许多检查来实现类似的目的.

可能不是你想听到的，但如果你想把它做对，你需要在两个层级上执行规则.

I've done some web-based projects, and most of the difficulties I've met with (questions, confusions) could be figured out with help. But I still have an important question, even after asking some experienced developers: When functionality can be implemented with both server-side code and client-side scripting (JavaScript), which one should be preferred?

A simple example:

To render a dynamic html page, I can format the page in server-side code (PHP, python) and use Ajax to fetch the formatted page and render it directly (more logic on server-side, less on client-side).

I can also use Ajax to fetch the data (not formatted, JSON) and use client-side scripting to format the page and render it with more processing (the server gets the data from a DB or other source, and returns it to the client with JSON or XML. More logic on client-side and less on server).

So how can I decide which one is better? Which one offers better performance? Why? Which one is more user-friendly?

With browsers' JS engines evolving, JS can be interpreted in less time, so should I prefer client-side scripting?

On the other hand, with hardware evolving, server performance is growing and the cost of sever-side logic will decrease, so should I prefer server-side scripting?

EDIT:

With the answers, I want to give a brief summary.

Pros of client-side logic:

1. Better user experience (faster).
2. Less network bandwidth (lower cost).
3. Increased scalability (reduced server load).

Pros of server-side logic:

1. Security issues.
2. Better availability and accessibility (mobile devices and old browsers).
3. Better SEO.
4. Easily expandable (can add more servers, but can't make the browser faster).

It seems that we need to balance these two approaches when facing a specific scenario. But how? What's the best practice?

I will use client-side logic except in the following conditions:

1. Security critical.
2. Special groups (JavaScript disabled, mobile devices, and others).

解决方案

In many cases, I'm afraid the best answer is both.

As Ricebowl stated, never trust the client. However, I feel that it's almost always a problem if you do trust the client. If your application is worth writing, it's worth properly securing. If anyone can break it by writing their own client and passing data you don't expect, that's a bad thing. For that reason, you need to validate on the server.

Unfortunately if you validate everything on the server, that often leaves the user with a poor user experience. They may fill out a form only to find that a number of things they entered are incorrect. This may have worked for "Internet 1.0", but people's expectations are higher on today's Internet.

This potentially leaves you writing quite a bit of redundant code, and maintaining it in two or more places (some of the definitions such as maximum lengths also need to be maintained in the data tier). For reasonably large applications, I tend to solve this issue using code generation. Personally I use a UML modeling tool (Sparx System's Enterprise Architect) to model the "input rules" of the system, then make use of partial classes (I'm usually working in .NET) to code generate the validation logic. You can achieve a similar thing by coding your rules in a format such as XML and deriving a number of checks from that XML file (input length, input mask, etc.) on both the client and server tier.

Probably not what you wanted to hear, but if you want to do it right, you need to enforce rules on both tiers.

这篇关于客户端逻辑还是服务器端逻辑?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！