網站前後端分離什麼意思

⑴ Web項目開發為何要走前後端分離模式

把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發，開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專注於具體業務邏輯。具體好處有以下幾點：

1.徹底解放前端

前端不再需要向後台提供模板或是後台在前端html中嵌入後台代

2.提高工作效率，分工更加明確

前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。

3.局部性能提升

通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。

4.降低維護成本

通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。

5.實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。

6.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。

7.可以使後台能更好的追求高並發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。

我理解的前後端分離，前端是需要起伺服器的，減少學習成本，可以用node，前端也要有域名的

如果是半分離， 那麼前端提供js文件（css等）這個我也做過，前後端都用node就不說了，如果是兩種語言，

如果一個工程文件下開發，webpack下直接打包進後台語言的靜態目錄下。

如果是兩個工程，那麼前端只提供生成的js（css）文件，git pull後台項目，扔進靜態目錄，這樣又涉及到版本控制的問題，一般我會生成一個配置文件，直接讀取的，內容是xxx.hash.js這種文件名，然後document.wirte動態寫入js/css

前端起伺服器就不需要動態引入了，直接html插件生成文件，更好的控製版本

半分離 還有一個問題，例如首頁同構，如果更改xxx.blade.php文件，這就又動了php文件，甚至包括nginx反向代理啊，ssl這種緩存啊，都比較麻煩，你要是改了點啥，自己的ok了，後台的崩了，那就挺操蛋了，大公司有專門的運維還好，小公司真的是一團糟

後台我們採取全分離，nginx前端管理，至於升級nginx版本，http2，反向代理，https證書，都是前端自己弄，畢竟小公司，每個人水平都不一致，自己負責自己的比較好

但是這個跨域又要稍微處理一下，至今我這邊後台還是*，我也沒法說什麼

阿里雲這么便宜，如果把成本浪費在人力上，會變得很貴

一個人的精力有限，前後端分離有助於我們更專注我們所要注重的技術點，俗話說：「術業有專攻」。

比如我們後端，前後端分離有助於我們把注意力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分布式架構（bbo，bbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。

而前端也可以集中精力在前端的展示上。

總的來說，前後端分離利大於弊。這也是越來越少用jsp的原因。

補充兩點

1.每次請求的數據量變小，也意味著更少的響應時間。

2.也不是每個應用用前後端分離都是最合適的，要根據應用規模，工期綜合判斷。

⑵ 現在開發網站一般都使用什麼方式什麼是前後端分離

前後端分離的由來是：以前開發網站都是 jsp、asp 這類動態腳本。
jsp、asp這種參雜了後端語言、javascript、css、html 的混合腳本，使代碼開發和維護都極其不方便。
隨著前端交互越來越復雜，jsp、asp 這種腳本語法已經不能滿足開發的需求了。
於是前後端的概念就提出了：前端人員負責頁面展示和交互，然後通過 ajax 調用後端人員寫好的數據介面。
所以開發網站的核心現在基本上就是：

html + css ：頁面展示
javascript + ajax（這個算是瀏覽器的一部分，可以通過 javascript 調用） : 頁面交互、邏輯處理
通常的開發框架選擇：

簡單網站： jquery + bootstrap
後台管理系統： angularjs + jquery + bootstrap + webpack
復雜的產品： react + rex + webpack

⑶ web開發為什麼要前後端分離

在學習前端開發的時候，會發現前端開發的知識非常瑣碎，前端往往是靠拼湊來完成頁面效果，開發過程沒有java後端開發有邏輯，代碼也很難管理。後端開發有各種各樣的工具類、jar包、maven依賴、spring框架等，具有工程化模塊化思維，可以滿足後期的優化。vue.js和react.js等這些前端框架的出現，它們從本質上打破了以前前端開發的規則，這就是前端開發組件化框架。這些框架出現後，前端開發也開始像後端一樣，遵循一套體系來進行約束性的開發，越來越工程化、組件化、迭代化，變得有章可循。前後端分離核心思想是前端HTML頁面通過AJAX調用後端的RESTFUL API介面並使用JSON數據進行交互。

⑷ web開發中，什麼是前後端分離

優秀的WEB架構，必定會應用一些分層設計的思想，這樣可以讓系統開發起來更靈活，同時後期維護也比較方便。

• 前端的頁面基本都是使用 JavaScript 的富戶端頁面，主要應用的框架用，jquery、jquery ui、knockout js、Durandal。

• 自己封裝的 UI 組件，後端的主要採用到的技術有 OData、MVC、Linq to SQL 以及自己寫的一個許可權管理組件，資料庫採用的是 SQL Server 2005。

⑸ Web 前後端分離的意義大嗎

什麼是前後端分離？前後端分離說白了就是把前端和後端分成兩個工程，由不同的團隊負責開發，這樣從工程和職責的角度上都有分開，這樣，後端偏向於提供單純的API介面，前端就是調用API介面進行展示和業務調用。
這樣不僅將頁面渲染和業務邏輯從server剝離開來，將頁面渲染放給前端，甚至放給瀏覽器；將業務邏輯放給後台專心搞業務，降低了他們之間的耦合性，而且從職責上進行了分明，更適合大項目和大團隊管理和開發。

⑹ 怎麼理解前後端分離

對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全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類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。

⑺ 什麼是前後端分離為什麼分離

在不使用vue ,react ,anglar這類的框架的情況下，前後端分離應該如何做？
需求是這樣：
前端寫html頁面（非單頁面應用），
index 首頁
about 關於我們
newslist 新聞列表
newsdetail 新聞詳情
proctlist 產品列表
proctdetail 產品詳情
後台只提供json數據
那麼
1、前端數據如何渲染？
2、頁面跳轉是否必須使用路由？（不想使用路由）
3、頁面間的數據傳遞如何做，比如：列表頁到詳情頁的參數傳遞如何做？

⑻ 什麼是前後端，有沒有前後端分離，還有如何區分mvc與前後端分離

1>>前後端分離的意思是，前後端只通過 JSON 來交流...

同意其他幾位，JSON 只是一種可選的協議，而不是唯一，也未必是前後端通信的最佳方案。

2>>組件化、工程化不需要依賴後端去實現...有哪些好處或弊端？

前端的組件化、工程化，js 等代碼越來越胖，有點類似於過去 C/S 時代的 fat client。所以這個問題相當於，計算是主要放在 client 好，還是 server 好？

Fat client 好，還是 thin client 好，取決於所開發應用、產品、系統的類型、規模和特點，其中一些權衡因素主要包括軟體復雜度、人機交互模型、網路帶寬、server 與 client 的處理能力等等。無所謂好壞，適合就好。

Client-side MVC 確實是一個趨勢，Web 架構設計上的一個創新。