2012-05-07 25 views
0

對於瞭解MVC而言是新的。用於劃分庫中前端和後端邏輯的啓發式方法,如backbone.js

我想知道是否有一個啓發式(非編程語言)在那裏進行劃分和決定什麼邏輯去前端而不是後端,特別是使用像backbone.js前端庫時。

即,像Backbone.js的庫從DOM元素使其成爲創建複雜的客戶端邏輯的是,也許,使用要在服務器側進行有用單獨的數據。

在此先感謝 喬伊

+0

歡迎來到Stackoverflow!請記住要提供所有您認爲有用的答案,包括那些適合他人問題的答案。記得檢查/接受你自己問題的最佳答案。 –

+0

看起來我不能upvote不幸的東西,因爲我是n00b – JoeyC

回答

2

「經典」的方式做模型 - 視圖 - 控制器是在服務器上的所有三個。然後,瀏覽器呈現HTML和一些JS的View層輸出。

Rails就是一個很好的例子。

「新酷」的辦法就是把瀏覽器與後端服務器通過API提供services主要計算引擎。

在這種情況下,客戶端上的模型,視圖和控制器軟件的所有運行(如JavaScript或CoffeeScript的)。骨幹網通常是瀏覽器端解決方案的一部分,但它有其他的選擇,如spine,angularJS等。

在後端服務器上,運行數據庫管理系統和良好的API系統。 Ruby/Rack上有一些很好的框架。查看Daniel Doubrovkine的帖子code.dblock.org你在這裏有很多選擇。在客戶端上MVC的

優勢

  • 用戶
  • 酷Ajaxy單頁效果
  • 單頁面的Web程序可以提供更快的用戶界面,用戶比普通網站
  • 響應的用戶界面
  • 良好的體系結構,使目標構建iPhone/Android應用程序
  • 根據應用程序,可用於創建標準獨立的webapps,沒有網絡連接。
  • 這是很多時尚的年輕人都在做這些天

缺點

  • 需要對舊的瀏覽器,IE瀏覽器的方式決定,等
  • 使可用內容的搜索引擎可以很棘手。可能需要陰影網站只爲搜索引擎
  • 測試可能是一個挑戰。但看到新的庫,如包含可測試性焦點的AngularJS
  • 這種方法涉及更多的軟件:編寫和測試需要更長的時間。

選擇

這是給你的。決定取決於你的時間表,資源,經驗,需求等等。不需要使用主幹或類似的。這樣做是一種折衷(見上文)。不使用它總是會更快/更容易,但沒有它(或類似)的做法可能無法實現您的目標。

您可以使用Rails或帶有附加庫或其他MVC解決方案的PHP構建一個出色的MVC應用程序。

+0

好的答案,但它真的解決OP的問題嗎?問題不是「邏輯:客戶端還是服務器?」但是「邏輯:如何分解它?」。儘管如此,對於客戶端MVC的優點和缺點的詳細分析,還是+1。 – nrabinowitz

+0

我同意 - 非常好的細分。 – JoeyC

1

我覺得你用這個詞啓發在非計劃性的意義是否正確?即你用它來表示「經驗法則」的含義?

作爲一個經驗法則:

  • 您希望服務器渲染UX和搜索引擎優化的原因,初始頁面加載。
  • 由於相同的原因,您也可以爲服務器呈現後續的AJAX部分頁面加載。配置文件查看哪個更快:讓服務器通過網絡傳輸額外的數據(標記),併發送更簡潔的負載(使用JSON)並讓客戶端進行渲染。有折衷尤其是當你考慮到在客戶端上渲染可能會慢一些考慮移動設備,但再有移動設備在那裏與互聯網連接速度較慢...
  • 像任何客戶端 - 服務器架構:你想要的客戶端在客戶端上執行需要快速響應的事情,然後將一些異步操作發送到執行相同任務的服務器。

帶走是含糊不清的,但是真實的:這完全取決於權衡,你必須決定你的產品需要什麼。

+0

謝謝。所以基本上沒有硬性和快速,它只取決於:) – JoeyC

0

前兩件事情浮現在腦海中,我是安全&搜索..

  • 你總是會希望限制讀取服務器上/寫訪問。
  • 在大多數情況下,您希望儘可能使您的搜索功能儘可能接近數據。