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

[朱涛 Tower Joo]

大家好!

在做过几个基于web的项目后, 碰到了一个比较难把握的问题: 在实现同一个功能时, 我们应该选择服务器端逻辑还是客户端的逻辑?

举个简单的例子:

功能: 我现在想动态地显示一个页面

方案1: 服务器端的逻辑: 从数据库里取出数据使用服务器端代码(PHP,python)来生成格式化后的页面,返回给客户端, 然后客户端直接显示.(所谓的more server side logic, less client side logic)

方案2: 客户端的逻辑: 从数据库里直接取出数据, 并不格式化,而是以json或者xml返回给客户端,让客户端的代码(javascript)来格式化,继而显示(所谓的more client side logic, less server side logic)

当然上面只是一个简单的例子, 可以推广到各种ajax的动态请求场景.

从用户的角度来看,二者的结果是一致的,但是程序员在处理时却是截然不同的. 所以出现了下面的几个问题:

1. 我们应该优先选择哪种?
2. 哪种有更好的performance?
3. 哪种更user-friendly?

这个问题, 我同时也在SO上进行了讨论,大家可以参见这里: http://stackoverflow.com/questions/1516852/client-side-logic-or-server-side-logic

从回答的答案来看, 也没有取得一个统一的结果,主要有下面几个观点

支持服务器端逻辑:

1. 安全性
2. 搜索引擎友好
3. 有更好的accessibility
4. 更好的适应性(无论用户使用的是支持js或者不支持的)
5. 用户体验的稳定性(由于不知道用户使用的是什么浏览器,也就不能确定js引擎的解析速度,所以可能某些浏览器用户会觉得很友好,而某些会觉得很慢,而使用服务器端则取决于网络)
6. 硬件成本的降低(这也是可预期的)

客户端的逻辑:

1. 用户友好(不需要refresh,而且通常会有更好的异步处理,所谓的ajax)
2. 节省带宽,减少成本(当然传输pure data的json肯定会比格式化好的html节省更多的带宽)
3. 扩展性(这点可能比较有争议,但是保持服务器端逻辑的简洁对于扩展性还是很有帮助的)
4. 现代浏览器的发展(IE,FF, chrome相继宣称自己有更快的js引擎,所以js的解析速度会有大幅度的提升,而且使用老浏览器的用户也是极少的)

好像是各有道理,那么可能更好的办法是both,于是一个新问题就出来了: 在何种场景下使用何种策略? 在可预期的未来, 哪种方式更要优先考虑呢?

我个人的见解是除了下面几种情况外,我都会优先使用客户端的逻辑:

1. 安全性(如一些验证, 也就是状态更改相关的)
2. 特殊人群(可能某些人群具有特殊的属性,如果我们的服务是针对这些人的,可能就要好好权衡)

希望有经验的朋友能够给出一些比较有说服力并且可操作的方法来(比如应用场景),也请解释下相应的原因.

谢谢.

--
Tower Joo 朱涛

homepage: http://sites.google.com/site/towerjoo/

blog: http://www.cnblogs.com/mindsbook/

>>> import this

[四不象]

如果涉及用户交互，那就采用2，比如大部分web2.0的网站

如果是无session，无交互，仅仅呈现数据，那就采用1，比如说CMS系统的前台页面

[高岩]

在国内，IE6的份额还是很大的

On 10月5日, 上午10时40分, 朱涛 Tower Joo <zhutao.is...@gmail.com> wrote:
> 大家好!
> 在做过几个基于web的项目后, 碰到了一个比较难把握的问题: *在实现同一个功能时, 我们应该选择服务器端逻辑还是客户端的逻辑?*
> *
> *
> *举个简单的例子:*
> *功能: 我现在想动态地显示一个页面*
> *方案1: 服务器端的逻辑: 从数据库里取出数据使用服务器端代码(PHP,python)来生成格式化后的页面,返回给客户端,
> 然后客户端直接显示.(所谓的more server side logic, less client side logic)*
> *方案2: 客户端的逻辑: 从数据库里直接取出数据,
> 并不格式化,而是以json或者xml返回给客户端,让客户端的代码(javascript)来格式化,继而显示(所谓的more client side
> logic, less server side logic)*
> *
> *
> *当然上面只是一个简单的例子, 可以推广到各种ajax的动态请求场景.*
> *
> *
> *从用户的角度来看,二者的结果是一致的,但是程序员在处理时却是截然不同的. 所以出现了下面的几个问题:*
>
> 1. 我们应该优先选择哪种?
> 2. 哪种有更好的performance?
> 3. 哪种更user-friendly?
>
> 这个问题, 我同时也在SO上进行了讨论,大家可以参见这里:http://stackoverflow.com/questions/1516852/client-side-logic-or-serve...
>
> 从回答的答案来看, 也没有取得一个统一的结果,主要有下面几个观点
> 支持服务器端逻辑:
>
> 1. 安全性
> 2. 搜索引擎友好
> 3. 有更好的accessibility
> 4. 更好的适应性(无论用户使用的是支持js或者不支持的)
> 5.
> 用户体验的稳定性(由于不知道用户使用的是什么浏览器,也就不能确定js引擎的解析速度,所以可能某些浏览器用户会觉得很友好,而某些会觉得很慢,而使用服务器端则取决于网络)
> 6. 硬件成本的降低(这也是可预期的)
>
> 客户端的逻辑:
>
> 1. 用户友好(不需要refresh,而且通常会有更好的异步处理,所谓的ajax)
> 2. 节省带宽,减少成本(当然传输pure data的json肯定会比格式化好的html节省更多的带宽)
> 3. 扩展性(这点可能比较有争议,但是保持服务器端逻辑的简洁对于扩展性还是很有帮助的)
> 4. 现代浏览器的发展(IE,FF,
> chrome相继宣称自己有更快的js引擎,所以js的解析速度会有大幅度的提升,而且使用老浏览器的用户也是极少的)
>
> 好像是各有道理,那么可能更好的办法是both,于是一个新问题就出来了: *在何种场景下使用何种策略? 在可预期的未来, 哪种方式更要优先考虑呢?*
>
> 我个人的见解是除了下面几种情况外,我都会优先使用客户端的逻辑:
>
> 1. 安全性(如一些验证, 也就是状态更改相关的)
> 2. 特殊人群(可能某些人群具有特殊的属性,如果我们的服务是针对这些人的,可能就要好好权衡)
>
> 希望有经验的朋友能够给出一些比较有说服力并且可操作的方法来(比如应用场景),也请解释下相应的原因.
>
> 谢谢.
> *
> *--

[朱涛 Tower Joo]

写了一篇关于这个话题的博文, 大家可以参考.

http://www.cnblogs.com/mindsbook/archive/2009/10/05/client-side-logic-or-server-side-logic.html
--
Tower Joo 朱涛

>>> import this

2009/10/5 高岩 <hal...@gmail.com>

[ZhiGang Qi]

安全性怎么体现的没有看出来。。。

2009/10/4 朱涛 Tower Joo <zhutao...@gmail.com>

--
Zhigang Qi
345 park ave, W12-302
San Jose , CA 95110, USA
Cell: (812)272-1809
work: 408-536-247
http://www.qizhigang.com

[朱涛 Tower Joo]

简单的一个例子是表单验证, 即使你在客户端用js来验证邮件地址,表项是否为空等, 这些仍远远不够,因为用户可以跳过这些客户端的验证(模板浏览器行为)而直接提交给服务器,这时如果服务器端没有相应的验证机制,自然会带来安全性问题.

--
Tower Joo 朱涛

>>> import this

2009/10/5 ZhiGang Qi <zhiga...@gmail.com>

[Jianshi Huang]

2009/10/5 朱涛 Tower Joo <zhutao...@gmail.com>:
> 简单的一个例子是表单验证, 即使你在客户端用js来验证邮件地址,表项是否为空等,
> 这些仍远远不够,因为用户可以跳过这些客户端的验证(模板浏览器行为)而直接提交给服务器,这时如果服务器端没有相应的验证机制,自然会带来安全性问题.

作为服务器的一切输入都需要验证，这个例子不能说明服务器端存在劣势。

逻辑也分UI逻辑和模型逻辑，其实我认为楼主要问的是，MVC中的 Controller 是放在服务器端好还是客户端好。

作为一个程序员，我的观点是放在客户端更好，因为在同一个程序语言(js)，同一个环境(js
解释器)中表达状态是最方便的(stack就是最直接的表现程序状态)，不需要任何 inversion of control,
或者大量的状态变量。而简洁清晰的服务器端接口，也方便了自动测试和调试。

--
黄　澗石 (Jianshi Huang)
http://huangjs.net/

[sagasw]

除了安全，想补充一点,比如sina这样的新闻站点,或者一些比较大型的内容为主的网站,都会构建代理+缓存机制，这个时候，实现服务器端逻辑反而要更简单。

2009/10/5 朱涛 Tower Joo <zhutao...@gmail.com>

大家好!

[Jiahua Huang]

现在有了 Chrome Frame

让 IE6 用户访问自己页面时使用 CF 就可以了

[四不象]

CF只是个试验性质的东西。

一般来说，现在还在用IE6的都是电脑技术白痴，他们可能连安装软件都不会。CF对这种用户而言太复杂了。

我不太看好CF，除非他能以类似ActiveX插件的形式发布

2009/10/5 Jiahua Huang <jhuang...@gmail.com>

--
水仙欲上鲤鱼去
一夜芙蓉红泪多

[Jiahua Huang]

看来你只是听说过有 CF 这么个东西啊。

要知道，CF 安装起来跟 支付宝等 ActiveX 控件没什么不同，

只要你的网页插入那两行标记，

IE6 下就会提示用户是否安装 CF，

你口中的“白痴用户”跟支付宝一样点下 确定 就可以了

[四不象]

所以说交互式webapp和cms前台类型的要区别对待

[四不象]

原来如此啊，我确实没有具体了解过，好像要通过在url前添加"cf:"才能激活chrome frame，不过听说有第三方"补丁"来弥补

2009/10/5 Jiahua Huang <jhuang...@gmail.com>

--
水仙欲上鲤鱼去
一夜芙蓉红泪多

[Jiahua Huang]

没去了解的东西就不要乱附和啦，

你说的那个，是 “可以”，而非“才能”。

在 URL 前添加 cf: 指的是手工显式使用 CF 渲染网页，注意这是“可以”，而非“必须”

（还可以自己修改注册表 HKCU\Software\Google\ChromeFrame\OptInUrls 添加需要的 URL）

而在通常情况（正常情况）下，是 网页作者在  html 的 <head> 里加入一行类似

<meta http-equiv="X-UA-Compatible" content="chrome=1">

以让 IE 使用 CF 显示网页，

就是说，是否使用 CF，是网页/网站所有者决定的，

并不需要所谓“IE6 白痴用户”去额外干点什么“高难度动作”

而让 IE6 下自动提示安装 CF，则是网页里添加类似下边的代码

<script type="text/javascript" 

src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"> </script>

<script>

CFInstall.check({

node: "placeholder",

destination: "http://www.waikiki.com"

});

</script>

默认这会在没装 CF 的 IE6 页面顶层显示一个浮动窗口（iframe）的安装提示

[ZhiGang Qi]

用户输入（Input）永远都是要服务器端验证的。
Output 用客户端格式化，这是目前主流。
你下面说的这个例子不是一个好的证据。


如果Input只用客户端js来验证的话。。。。谁会这样做？？？ noob?

[Pink.Bear]

以后国内的智能手机和移动网络发展起来之后，面向各种不特定浏览器和不特定硬件环境的话，使用服务器端逻辑似乎是唯一的选择了。

2009/10/5 sagasw <sag...@gmail.com>

[Pink.Bear]

窃以为，让用户在AAA的时候使用BBB是一种非常用户不友好的设计思想。

2009/10/5 Jiahua Huang <jhuang...@gmail.com>

[Pink.Bear]

很多时候，不是用户想用IE6，是他们不得不使用IE6。
在被剥夺了Admin权限的情况下，从IE6升级到IE8和安装CF都是不可能的。

2009/10/5 Jiahua Huang <jhuang...@gmail.com>

[朱涛 Tower Joo]

 这个例子是说明在同一功能的实现逻辑上(验证表单)可以选择客户端逻辑, 也可以选择服务器端逻辑,譬如email验证, 显然二者都可以达到目的(正常用户), 但是客户端的逻辑是存在安全隐患的, 这也就是例子中提到的绕开客户端验证的逻辑来直接提交给服务器.

我觉得用这个例子来说明安全性问题是比较恰当的.

至于永远不要相信用户的输入,  这是另一范畴的概念, 与本例子要说明的问题不相关.

[ZhiGang Qi]

第一：
有些逻辑是必须放在服务器端的，无论你选择什么架构。
用户输入验证就是一个必须放在服务器端的例子。这也是为什么这个例子不适合来说明安全性。

第二：
如果客户端逻辑存在安全性问题的话，那根本就不能被采用，没有一个公司或者网站愿意承受这样的危险。 仅仅这一条，就可以直接否决。

2009/10/5 朱涛 Tower Joo <zhutao...@gmail.com>

 这个例子是说明在同一功能的实现逻辑上(验证表单)可以选择客户端逻辑, 也可以选择服务器端逻辑,譬如email验证, 显然二者都可以达到目的(正常用户), 但是客户端的逻辑是存在安全隐患的, 这也就是例子中提到的绕开客户端验证的逻辑来直接提交给服务器.

[靳禹| yu jin]

随着网络技术和终端技术的增强，这两个概念会不会更模糊化呢？

2009/10/5 Pink.Bear <mr.be...@gmail.com>

--
靳禹@bjut
-Its not trial but struggle

[靳禹| yu jin]

顺便请教下，哪位对HTML5有所了解？

2009/10/5 靳禹| yu jin <jinyu...@gmail.com>