1樓：du知道君
1>>前後端分離的意思是，前後端只通過 json 來交流...
同意其他幾位，json 只是一種可選的協專議，而不是唯屬一，也未必是前後端通訊的最佳方案。
2>>元件化、工程化不需要依賴後端去實現...有哪些好處或弊端？
前端的元件化、工程化，js 等**越來越胖，有點類似於過去 c/s 時代的 fat client。所以這個問題相當於，計算是主要放在 client 好，還是 server 好？
fat client 好，還是 thin client 好，取決於所開發應用、產品、系統的型別、規模和特點，其中一些權衡因素主要包括軟體複雜度、人機互動模型、網路頻寬、server 與 client 的處理能力等等。無所謂好壞，適合就好。
client-side mvc 確實是一個趨勢，web 架構設計上的一個創新。
對於前後端分離專案，還適合使用springmvc嗎
2樓：萢萢
不知道你說的前後端分離
是指前後端有關係分開來開發
還是指前後端沒有關係
如果是前後端有關係分開開發
spring mvc適合使用
如果前後端沒有關係
可以考慮使用其它技術或方式實現
請教用asp.*** mvc的都是前後端分離嗎
3樓：藤原子大雄
在解決方案中新增一類庫專案作為controller，在**專案中引用該類庫專案。
前後端分離和mvc開發模式哪個好
4樓：匿名使用者
個人建議前後端分離，稍微大一點的團隊合作開發的時候一般都是使用這種方式。現在比較流行的angularjs等，後臺可以考慮用mvc web api
web專案開發為何要走前後端分離模式？
5樓：幽豆逗
畢竟只有前後端都走分離模式才可以促進這個專案的發展
6樓：哈哈哈
因為現在的前後端分離模式是非常高超的，利潤度是非常的高的。
7樓：風蜂蜜柚子茶
因為只有前後端分離的模式才能適應這個專案的開發。
8樓：夢醒時分緣何為
因為只有這樣這個專案才能夠往前推進不是的嗎
9樓：匿名使用者
麻煩不要再搞什麼前後端分離了好吧，後端人員寫介面文件，對介面更痛苦了，反反覆覆改**，浪費時間，浪費精力。效率明明更差了
10樓：吹氣球小男孩
那時候的一些專案都只有一個包，沒有什麼**規範，業務邏輯散落在各處，甚至是jsp中直接訪問資料庫並做業務處理。
11樓：我是跳閘了
因為這就是未來發展的趨向的，所以才會這樣的。
12樓：瓶蓋缺塞兒
這個是為了更好的為生活和其他方面提供更好的幫助。
13樓：匿名使用者
分為前端和後端有他自己的戰略經營,是沒有錯的
spring mvc前後端分離後臺**請求分開嗎
14樓：弊頻贍此茨
不知道你說的前後端分離 是指前後端有關係分開來開發 還是指前後端沒有關係 如果是前後端有關係分開開發 spring mvc適合使用 如果前後端沒有關係 可以考慮使用其它技術或方式實現
前後端分離開發是個什麼概念,跟我們用的框架有什麼不同啊
15樓：安徽新華電腦專修學院
就是後端給 api ，客戶端渲染。完全的前後端分離也是一步一步發展過來的。
現在開發**一般都使用什麼方式？什麼是前後端分離
16樓：折柳成萌
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全ajax，使用angular或者什麼什麼就可以了。
這個說法是不合適的，打個比方，別人問的是「如何解決家禽把蛋生在水草邊的問題？」，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答「不讓去水邊就行了」，這顯然不在點子上。
這兩年業界說的前後端分離，是限於偏展示類的系統（用a代替），而不是應用、管控類web專案（用b代替），在b類專案裡，前後端是天然分離的，對此，除了
少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是隻做b類專案，在b類專案裡，前後端分離是共識，不需要討論。
那麼，剩下的問題就是討論a類專案的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與資料結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：
模板應當由前端人員去控制，主要原因有兩方面：
- 效能優化（尤其是外部資源的管理與釋出，請求合併等等）
- 協作的順暢性（已形成模板的介面片段的返工等問題）
那麼，模板到底應該在什麼地方跟資料結合？
這個問題就比較折騰了，有部分人嘗試像b類專案那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏效能不夠，尤其對於首頁dom量很大的電商類**，差距很明顯。
所以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入node層，在這一層把模板與資料進行合成，然後瀏覽器拿到的就
是生成好的html了，但也不是所有html都是這麼生成好的，還是會有一些內容等到了瀏覽器之後，再用js去載入和生成。
所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。
至於說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web專案的東西都可以，這個還是要看所在企業的技術積累方向，當然node
做這塊是有一些優勢的，比如對前端人員的語言友好性，前後端模板的通用性等等，但這些都是細節，重點還是整體方案和流程。
這時候回頭看你問題中的這句：
> 前後端分離的意思是，前後端只通過 json 來交流，元件化、工程化不需要依賴後端去實現。
我相信你這裡對前後端的限定是以瀏覽器為準的，但事實上，a類專案中，前後端的分界一定要延伸到伺服器端的模板層，也就是在這一層裡，把各種**的資料整合到模板中，這個資料未必是json格式的，會存在有json，xml，特定的二進位制等等。
元件化這個話題就更復雜了，在剛才組織形式中，很難說出究竟什麼才是元件。是某個商品的模板嗎？是資料嗎？是資料和模板的結合體嗎？沒法回答。在此，我說一
句自己的看法：像電商這種專案的前端部分，基本不存在元件的概念，甚至不存在元件化的價值，因為這裡面可複用的東西太少了，也不易提取，大多數東西都是不
帶邏輯的介面模板。
最近因為reactjs的流行，帶來了一個isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問
題，尚不得而知，根據我的理解，它對b類專案是較好的補充方案，但對a類專案暫時還缺乏可用性，因為a類專案中，執行期的dom變更並不多，多是整片的改
變，用這個方案去解決的話，有些牛刀殺雞的感覺。
關於b類專案的元件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
如何通過nodejs來實現php的前後端分離
原本返回html的php，現只返回資料，資料交由node拼接html，node和php必然要http，因為php web上有很多解決方案可以套用，比如負載均衡。概括起來兩個方法吧。方法一 string fdjborsnabcdtghrjosthabcrgrjtabc string preg repl...
如何處理好前後端分離的api問題
你好,懷孕28周後胎兒的腎盂分離不超過10mm就算正常,羊水最大深度正常在40 80mm之間,羊水指數就是子宮內四個角的羊水深度相加,正常在8.0 18cm之間。如何處理好前後端分離的 api 問題 意義很大,但是你的問題本身認識有偏差。對於前後端分離,認識上有個誤區,那就是很多人自稱 老早就分離了...
關於api的前後端分離的糾結關於API的前後端分離的糾結？
意義很大，但是你的問題本身認識有偏差。對於前後端分離，認識上有個誤區，那就是很多人自稱 老早就分離了，全ajax，使用angular或者什麼什麼就可以了。這個說法是不合適的，打個比方，別人問的是 如何解決家禽把蛋生在水草邊的問題？但實際上人家養的是鴨子，答題的卻是養雞的，所以回答 不讓去水邊就行了 ...