Re: [問題] 這樣的功能前端or後端做?

看板Ajax作者TonyQ (自立而後立人。)時間13年前 (2011/12/23 00:41)推噓4(4推 0噓 36→)

留言40則, 4人參與討論串4/4 (看更多)

※ 引述《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)

推

mrbigmouth

12/23 01:27, , 1^F

12/23 01:27, 1^F

→

mrbigmouth

12/23 01:29, , 2^F

12/23 01:29, 2^F

→

mrbigmouth

12/23 01:30, , 3^F

12/23 01:30, 3^F