客户端逻辑或服务器端逻辑?

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

一个简单的例子:

为了呈现一个dynamic的html页面,我可以在服务器端代码(PHP,python)中对页面进行格式化,并使用Ajax来获取格式化的页面并直接渲染(服务器端更多逻辑,客户端更less)。

我也可以使用Ajax来获取数据(不是格式化的,JSON),并使用客户端脚本来格式化页面,并进行更多的处理(服务器从数据库或其他来源获取数据,并将其返回给客户端与JSON或XML。更多的逻辑在客户端和less在服务器上)。

那么我怎样才能决定哪一个更好? 哪一个提供更好的性能? 为什么? 哪一个更方便用户?

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

另一方面,随着硬件的不断发展,服务器性能不断提高,服务器端逻辑成本也会下降,所以我更喜欢服务器端脚本?

编辑:

有了答案,我想简要总结一下。

客户端逻辑的优点:

  1. 更好的用户体验(更快)。
  2. 更less的networking带宽(更低的成本)。
  3. 增加可扩展性(降低服务器负载)。

服务器端逻辑的优点:

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

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

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

  1. 安全关键。
  2. 特殊组(禁用JavaScript,移动设备等)。

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

正如米高博尔所言,永远不要相信客户。 不过,我觉得如果你信任客户,这几乎总是一个问题。 如果你的申请值得写作,那么值得妥善保护。 如果任何人都可以通过编写自己的客户端并传递数据来打破它,那么这是一件坏事。 出于这个原因,你需要在服务器上进行validation。

不幸的是,如果您validation服务器上的所有内容,则通常会给用户带来糟糕的用户体验。 他们可能只填写一张表格,发现他们input的一些内容不正确。 这可能适用于“互联网1.0”,但今天的互联网上人们的期望更高。

这可能会使您编写相当多的冗余代码,并将其保留在两个或更多位置(某些定义(如最大长度)也需要在数据层中进行维护)。 对于相当大的应用程序,我倾向于使用代码生成来解决这个问题。 我个人使用UMLbuild模工具(Sparx System的Enterprise Architect)来模拟系统的“input规则”,然后利用部分类(我通常在.NET中工作)来生成validation逻辑。 您可以通过以XML等格式编写规则并从客户端和服务器层上的该XML文件(input长度​​,input掩码等)获取大量检查来实现类似的function。

可能不是你想听到的,但是如果你想正确地做,你需要在这两个层次上执行规则。

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

  1. 我不信任客户; 这可能或不是真正的问题,但它是习惯性的
  2. 服务器端减less了每个事务的数量(尽pipe它增加了事务的数量)
  3. 服务器端意味着我可以相当确定发生什么逻辑(我不必担心客户端浏览器可以使用Javascript引擎)

可能还有更多更好的理由,但现在这些是我头脑中最重要的。 如果我想到更多的话,我会添加它们,或者在我做之前将它们提出来。


使用客户端逻辑(使用Ajax / JSON)编辑, valya评论允许(更容易)创build一个API。 这很可能是真的,但我只能一半同意(这就是为什么我还没有投票答复)。

我的服务器端逻辑的概念是检索数据,并组织它; 如果我有这个权利的逻辑是“控制器”(MVC中的C)。 然后传递给“观点”。 我倾向于使用控制器来获取数据,然后“视图”处理将其呈现给用户/客户端。 所以我没有看到客户端/服务器的区别与创buildAPI的论点必然相关,基本上就是:马匹用于课程。 🙂

…作为一个业余爱好者,我承认我可能会略微扭曲MVC的用法,所以我愿意在这一点上进行纠正。 但是我仍然把这个陈述与逻辑分开。 就API而言,这种分离是非常重要的一点。

我通常实施尽可能合理的客户端。 唯一例外,使我去服务器端将解决以下问题:

信任问题

任何人都可以debuggingJavaScript和阅读密码,等等。

性能问题

JavaScript引擎正在快速发展,所以这个问题已经不再那么严重了,但是我们仍然处于一个以IE为主的世界,所以当你处理大量的数据时,事情变得缓慢。

语言问题

JavaScript是弱types的语言,它使你的代码有很多假设。 这可能会导致您采用令人毛骨悚然的解决方法,以便在某些浏览器上按照应有的方式工作。 我避免了像瘟疫这样的事情。


从你的问题,这听起来像你只是试图加载到表单的值。 除了上面的问题,你有3个select:

纯粹的客户端

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

纯服务器端

好处是你的页面会加载数据。 但是,数据的后续更新将需要刷新页面的所有/重要部分。

服务器 – 客户端混合

您将拥有两全其美的优点,但是您需要创build两个数据提取点,导致代码稍微膨胀。

每个选项都有权衡,所以你必须权衡他们,并决定哪一个给你最大的好处。

我没有听说过的一个考虑是networking带宽。 举一个具体的例子,我参与的一个应用程序都是在服务器端完成的,并且导致200Mb的网页被发送到客户端(如果没有大量重新devise应用程序的话,这是不可能的。 导致2-5分钟的页面加载时间。

当我们通过从服务器发送JSON编码的数据并让本地JS生成页面来重新实现这个function时,主要的好处是发送的数据缩小到了20Mb,结果是:

  • HTTP响应大小:200Mb + => 20Mb +( 相应的带宽节省 !)

  • 加载页面的时间:2-5分钟=> 20秒(其中10-15分钟被数据库查询占用,这个数据库查询已经被优化到更远的地方)。

  • IE进程大小:200MB + => 80MB +

请注意,最后2点主要是由于服务器端必须使用糟糕的table-tables-table树实现,而客户端允许我们重新devise视图层以使用更轻量级的页面。 但我的主要观点是networking带宽节省。

我构build了一个REST风格的Web应用程序,在没有JavaScript的情况下, 所有的 CRUDfunction都可用,换句话说,所有的AJAX效果都是严格的渐进式增强

我相信有足够的奉献精神,大多数Web应用程序可以这样devise,因此侵蚀了许多服务器逻辑与客户端逻辑“差异”,如安全性,可扩展性,在您的问题中提出,因为在这两种情况下,请求都被路由到相同的控制器,其业务逻辑直到最后一英里都一样,其中JSON / XML而不是整个页面的HTML被返回给这些XHR。

只有less数情况下,AJAX应用程序比静态应用程序更加先进,GMail是我想到的最好的例子,那么需要创build两个版本并将它们完全分开(Kudos to Google!)。

我想就这个问题给我两分钱。

我通常赞成服务器端的方法,这是为什么。

  • 更多SEO友好。 Google无法执行Javascript,因此search引擎将无法看到所有内容
  • 性能更可控。 由于您几乎完全依赖于用户浏览器和机器来渲染事物,因此用户体验总是随SOA变化的。 即使你的服务器运行的很好,一台慢速的用户也会觉得你的网站是罪魁祸首。
  • 可以说,服务器端的方法更容易维护和可读。

我用这两种方法写了几个系统,以我的经验,服务器端就是这样。 但是,这并不是说我不使用AJAX。 我所build立的所有现代系统都包含了这两个组件。

希望这可以帮助。

在这个阶段,客户端技术是领先的,随着Backbone,Knockout,Spine等许多客户端库的出现,并增加了诸如JSrender,胡子等客户端模板,客户端开发变得非常容易。 所以,如果我的要求是去互动的应用程序,我一定会去客户端。 如果你有更多的静态HTML内容,那么是去服务器端。 我做了两个实验,我必须说服务器端比客户端更容易实现。 就表演而言。 阅读这个,你会明白服务器端的性能分数。 http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

我知道这个post很老,但我想评论。

根据我的经验,最好的方法是使用客户端和服务器端的组合。 是的,Angular JS和类似的框架现在非常stream行,它们使开发轻量级Web应用程序变得更加容易,性能得到了提高,并且可以在大多数Web服务器上运行。 但是,企业应用程序的主要需求是显示报表数据,可以在一个页面上显示500多条logging。 使用返回大量数据列表的页面,用户通常需要使这个庞大列表易于过滤,search和执行其他交互function的function。 由于IE 11及更早版本的IE浏览器在大多数公司都是“首选浏览器”,所以您必须注意,这些浏览器仍然存在使用现代JavaScript,HTML5和CSS3的兼容性问题。 通常,要求是在所有浏览器上使网站或应用程序兼容。 这需要添加shiv或使用原型,这些原型与创build客户端应用程序所包含的代码一起添加到浏览器上的页面加载中。

所有这些都会降低性能,并可能导致可怕的IE错误“此页上的脚本正在导致Internet Explorer运行缓慢”,迫使用户select是否要继续运行脚本或不创build不良的用户体验。

根据他们在现有应用程序中的偏好,确定应用程序的复杂性以及用户现在想要的和将来可能需要的内容。 如果这是一个简单的网站或应用程序与中小型数据,使用JavaScript框架。 但是,如果他们想要包含可访问性, search引擎优化; 或者需要显示大量数据,使用服务器端代码来节省数据和客户端代码。 在这两种情况下,请使用Fiddler或Chrome Developer工具等工具来检查页面加载和响应时间,并使用最佳做法来优化代码。

使用ASP.NET Core开发Checkout MVC应用程序。

我认为第二个变种更好。 例如,如果你后来实现类似'皮肤'的东西,你会感谢你自己格式化HTML服务器:)

它也保持视图和控制器之间的差异。 Ajax数据通常由控制器生成,所以让它只返回数据,而不是html。

如果您稍后要创build一个API,则需要在代码中进行一些更改

另外,我认为,“裸”数据比HTML更容易擦除。 例如,如果你添加一些风格的链接,你需要重新格式化所有的HTML ..或添加一行到你的js。 它不像html(以字节为单位)那么大。

但是,如果需要使用许多繁重的脚本来格式化数据,那么不要求用户的浏览器对其进行格式化。

只要你不需要发送大量的数据给客户端来完成这个工作,客户端就会给你一个更加可扩展的系统,因为你正在为客户端分发负载,而不是把你的服务器做任何事。

另一方面,如果您需要处理大量数据以生成less量html以发送给客户端,或者如果可以优化使用服务器的工作来同时支持多个客户端(例如,处理数据一次并将所得到的html发送给所有的客户端),那么可以更有效地利用资源来完成其他服务器上的工作。

如果你在Ajax中做:

您必须为残疾人士考虑可访问性问题(在Google中search有关networking的辅助function),而且还需要考虑旧版浏览器,没有JavaScript的用户,漫游器(如google bot)等。

如果你从来没有用过很多的JavaScript,那么你就不得不调侃“渐进式增强”。 简而言之,您必须让您的应用程序适用于旧版浏览器和那些没有JavaScript的应用程序(例如某些移动设备),或者如果它被禁用。

但是,如果时间和金钱不是问题,我会逐渐提高。

但也要考虑“后退button”。 我讨厌它,当我浏览一个100%的AJAX网站,使你的后退button无用。

祝你好运!