问客户端逻辑还是服务器端逻辑？

EN

在许多情况下，我担心最好的答案是。

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

不幸的是，如果您验证服务器上的所有内容，通常会给用户留下很差的用户体验。他们填写表单后可能会发现他们输入的许多内容都是不正确的。这可能适用于“互联网1.0"，但在今天的互联网上，人们的期望更高。

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

可能不是您想要听到的，但如果您想做正确的事情，您需要在两个层上执行规则。

我倾向于使用服务器端逻辑。我的理由很简单：

Javascript

• 我不信任客户端；这可能是一个真正的问题，也可能不是一个真正的问题，但它的transactions)

• Server-side减少了每个事务的数量(尽管它确实增加了的数量，这意味着我可以相当确定正在发生什么逻辑(我不必担心客户端浏览器可用的

1. 引擎)

可能还有更多-and更好的理由，但这些都是我现在最关心的。如果我想到更多，我会添加它们，或者在我之前对那些提出它们的人投上赞成票。

​

编辑后，valya评论说，使用客户端逻辑(使用Ajax/JSON)允许(更容易)创建应用程序接口。这可能是真的，但我只能半同意(这就是为什么我还没有投票支持这个答案)。

​

我对服务器端逻辑的概念是检索数据并对其进行组织；如果我没有弄错的话，那么这个逻辑就是“控制器”(MVC中的C)。然后将其传递给“视图”。我倾向于使用控制器来获取数据，然后“视图”处理将数据呈现给用户/客户端。因此，我不认为客户机/服务器的区别必须与创建API的争论相关，基本上就是:以马换课。:)

...also，作为一个业余爱好者，我意识到我对MVC的使用可能有一点扭曲，所以我愿意纠正这一点。但我仍然将演示与逻辑分开。就API而言，这种分离是最大的优点。

我通常会在合理的客户端实现尽可能多的内容。唯一会让我转到服务器端的例外情况是解决以下问题：

信任问题

任何人都有能力调试JavaScript和读取密码，等等。

性能问题

JavaScript引擎正在快速发展，所以这不是什么大问题，但我们仍然处于IE主导的世界，所以当你处理大量数据时，事情会变慢。

语言问题

JavaScript是一种弱类型语言，它对您的代码做了很多假设。这可能会导致您使用诡异的变通方法，以便让事情在某些浏览器上以它们应该的方式工作。我避免这种事情，就像瘟疫一样。

从您的问题看，您似乎只是在尝试将值加载到表单中。除非出现上述任何问题，否则您有3种选择：

纯客户端

缺点是用户的加载时间会加倍(一次加载空白表单，另一次加载数据)。但是，对表单的后续更新不需要刷新页面。如果会有大量的数据从服务器获取到同一个表单中，用户会喜欢这样的。

纯服务器端

这样做的好处是，您的页面将加载数据。但是，对数据的后续更新将需要刷新页面的所有/重要部分。

服务器-客户端混合

您可以两全其美，但是您需要创建两个数据提取点，这会导致代码稍微膨胀。

每个选项都有权衡，所以你必须权衡它们，并决定哪一个能给你带来最大的好处。