※ 引述《mrbigmouth (拒绝崩溃的蒲公英)》之铭言： : 在这种情况下，你需要的东西其实是Html产生器，一个帮你把资料变成Html页面的东西 : 如果这个过程就是TonyQ大大所说的"以特定格式储存再从伺服端取出"的"後端语言" : 那我认输，至少在这个情况下认输 : 因为整个处理过程根本只有一次嘛！当然是给处理能力最好的电脑去做.... : 但是 : 如果你的行事历至少需要多人编辑、依登入者身份可以随意插入、删除、变更工作内容 : 工作内容有分级、分块、分类，可以drill down跟roll up等等等的时候 : （依在下的不幸工作经验来看，所有一开始看来很简单的程式在之後八成都会 : 　在老板/使用者的要求下加东加西，最後变成这种万能的样子） : 换句话说,资料进出资料库的频率很大的时候 : 前端就远胜於後端了 其实以上我们是有共识的 也就是前端修改频繁的状况下，用 CLIENT 可以缩小更新的范围， 也可以有效的进行互动。所以我就不多谈了。 虽然我的表达应该让你有误会的地方， 我想主要的误会在於我是把整理资料切成两段的。 一段是纯vo (json) ，另一段才是 vo => html。 我相信你应该也有切这两段，只是你没有特别标明而已。 另外 SEO 议题也只是 add-on 顺便一提，你可以忽略这个子项没差， 他不是很重要的重点，也有别的方式可以补偿。XD 至於，我说的行事历是主要用来显示的状况下， 靠後端组html就好了， 除非你有必要再画面上点一点，日历上就加个新项目（不换页）。 或者画面上按一按，东西就少一项，（不换页）。 很多地方的作法是把新增删除的表单往别的地方甚至别的系统扔， 这种状况行事历就只会是捞出来显示。 这种情况，我不觉得非得要用前端不可啦， 反正小量的字串工作对後端真的是不痛不痒。 : 为什麽？ : 因为在工作交由後端处理的情形下，使用者每执行一次此类操作， : 伺服器就需要重新从DB捞一次资料、重新计算并且重新把资料传递给使用者 : 每次执行工作时,资料都需要跑一次DB->将原始资料编成适当格式->使用者的路程 : 而在前端处理的情况下，所有资料一进入记忆体就不太需要再从DB捞取，更不需要 : 再次经过网路传输的折磨 : 如下所示： : 状况： : A.使用者登入并浏览此月行程 : B.使用者浏览下个月行程 : C.使用者在下个月插入新行程 : D.使用者返回浏览此月行程 : E.使用者重新整理 : F.使用者drill down浏览今日行程 : 後端处理情形： : A.使用者资料传输给Server->验证使用者建立Session->从DB捞属於这个月的行程出来-> : 将原始资料编成固定格式->资料传输给使用者 : B.使用者资料传输给Server->确认使用者身份->从DB捞出下个月行程资料-> : 将原始资料编成固定格式->资料传输给使用者 : C.使用者资料传输给Server->确认使用者身份->将资料插进DB->从DB捞出新行程资料-> : 将原始资料编成固定格式->资料传输给使用者 : D.使用者资料传输给Server->确认使用者身份->从DB捞出这个月行程资料-> : 将原始资料编成固定格式->资料传输给使用者 : E.使用者资料传输给Server->确认使用者身份->从DB捞出这个月行程资料-> : 将原始资料编成固定格式->资料传输给使用者 : F.使用者资料传输给Server->确认使用者身份->从DB捞出今日行程资料-> : 将原始资料编成固定格式->资料传输给使用者 : 前端处理情形： : A.使用者资料传输给Server->验证使用者建立Session->从DB捞出所有使用者可见的行程 : 资料出来->以批次或者server-sent方式逐步传递给使用者->使用端将资料编成固定格式 : 展现 : B.使用端将资料编成固定格式展现 : C.使用者资料传输给Server->确认使用者身份->将资料插进DB->从DB捞出指定时间以後 : 有所异动的资料->资料传输给使用者->使用端将资料编成固定格式展现 : D.使用端将资料编成固定格式展现 : E.使用者资料传输给Server->确认使用者身份->从DB捞出指定时间以後有所异动的资料 : ->资料传输给使用者->使用端将资料编成固定格式展现 : F.使用端将资料编成固定格式展现 : 以上 以上这些我同意，如果你需要频繁操作，透过前端当然比较简单， 也可以只取你想要得部份。 : 最後 : 请不要把json说的好像不需要parse一样... : 无论是什麽格式的资料,从server端传过来的时候就只是字串 : 不管你是用eval还是各浏览器内建的parser, : 切CSV所花费的时间绝对小於转换json的时间 等等，我觉得你要不要说说你怎麽 parse CSV 的？ 就我所知 , csv 要嘛就是用regex , 要嘛就自己split "," . (不管split 或indexOf+substring) 有比这更快更方便的方式吗？ 我不是那麽常作csv，所以想确认一下。 如果没有，我觉得你的「绝对」要打个折扣。 : 使用资料的类别更是跟使用者体验八竿子打不着关系 : 只要用熟了就一点麻烦也不会有 这个前提是parse 需要花费时间，而花费时间动作多了 browser 会「钝钝的」。 当然我同意这种case底下，除非是ie6或ie7这种烂咖， 不然一般状况应该都没这问题。 : 当然,无论如何,前端花费的资源永远只是小case : 重点在於後端要传输资料的时候 : 你要输出json,就一定要先把所有资料存在记忆体里才能一次转换 并没这回事，你csv能怎麽做，json就能怎麽做。 如果你嫌一次转换一整个array太浪费资源， 你一笔一笔自己翻 string 转也可以，这是转换方法的问题。 没有人规定你要「一次转换」，事实上大量的资料我是不会这麽做， 这也是效能调校上的重点项目之一。 : 比如要把从DB resource读出的资料一笔笔全部存进阵列里...这过程是要吃记忆体的 : 小量的资料没感觉,如果是一千笔、一万笔资料呢?一个留言板的全部文章这种呢? : (特别是当使用语言是PHP阵列这种消费记忆体为实际N倍的怪物时) 你csv 能怎麽产，我就能怎麽产json。 : 从Server输出CSV就不会有这种问题 我觉得这只是你用不对等的方式再比较这两个东西。:P : json当然好用,我自己写ajax时也有超过一半是在用json : 但json比csv好的优势在於可以存进多层次、复杂的资料,而不是在效率 : 然後...从DB捞出来的原始资料,绝大多时候都是CSV能够处理的 这个我不认为，这可能跟资料操作的习惯有关系。 csv 是扁平的，那意味着每次的资料都是独一无二的， 你很难重用相同的资料在其他 request ... json 有弹性一点，不过这点要看设计习惯， 你觉得可以的话，我是不觉得有问题啦。 另外 json 可以透过 jsonp 轻松支援跨网域，这个弹性也是没话讲得。 : 在我上面所说的例子,当後端完全只负责捞DB与传输的情形下 : 完全可以使用CSV取代json,杀鸡焉用牛刀 有关 csv 跟 json parsing 的部份，我想数字会说话。 对 test case 或者测量方法有不满意的，可以自己改我们再来讨论， 我因为一时想不到啥好例子，也真的是很懒得再找csv parser， 所以找一个对 csv 来讲相对单纯的例子， 实务上，csv 还要考虑 "" 跟 , 的差别，还会再慢一点。 http://jsfiddle.net/jnAW3/1/ 这个我特地让 json 放点水，加上 "" 。 http://jsfiddle.net/jnAW3/2/ 本来想再测测 jsonp ，不过那个测试多少会被网路速度干扰，就算了。 基本上，如果你的资料超过八万笔，那真的已经算是很了不起的了， 这就是为什麽我不太理解你所谓的解 csv 比 json 快的论述在哪。 它在chrome跟firefox 的数字还蛮飘的，看不出明显差异， 在 IE 我的测试是相当明显，另外可以比较 ie6,ie7,ie8 ,fx,chrome 的。 在IE6,IE7 上的数字，那可不是小case， 尽可能降低资料的操作量一直都是 performance tunning 上的重点。 可能我的观念也不见得是对得，特别在效能议题上， 我们已经碰过很多次改个板，旧的观念就大洗盘的状况， 不过这个议题上到目前为止，我的论述只有两个： 1.csv parser 你要引用外部类别或者自己写复杂逻辑， 不好维护，也需要额外成本。（这是重点） 哪个是鸡哪个是牛刀还很难说... 2.效能上没有显着差异，所以我完全想不到， 任何用csv parser取代 json parser的理由。 当然，这可能是测试案例的问题，只是我的认知跟你的认知有出入， 如果你可以有更好得例子，能说明 CSV 的好处，那也很欢迎。 -- 网页上拉近距离的帮手 实现 GMail丰富应用的功臣 数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ 欢迎同好到 AJAX 板一同讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 198.203.175.175 ※ 编辑: TonyQ 来自: 198.203.175.175 (12/23 00:42) ※ 编辑: TonyQ 来自: 198.203.175.175 (12/23 00:44) ※ 编辑: TonyQ 来自: 198.203.175.175 (12/23 00:44) ※ 编辑: TonyQ 来自: 198.203.175.175 (12/23 00:46) ※ 编辑: TonyQ 来自: 198.203.175.175 (12/23 01:08) ※ 编辑: TonyQ 来自: 208.54.38.134 (12/23 04:25)