① 貴陽北大青鳥：前後端分離的特點
我們在開發軟體和app應用的時候一般都會採用不同的分離模式，下面我們就一起來了解一下，前後端是否分離都有哪些影響與作用。
前後端不分離在前後端不分離的應用模式中，前端頁面看到的效果都是由後端控制，由後端渲染頁面或重定向，也就是後端需要控制前端的展示，前端與後端的耦合度很高。
這種應用模式比較適合純網頁應用，但是當後端對接App時，App可能並不需要後端返回一個HTML網頁，而僅僅是數據本身，所以後端原本返回網頁的介面不再適用於前端App應用，為了對接App後端還需再開發一套介面。
前後端分離在前後端分離的應用模式中，後端僅返回前端所需的數據，不再渲染HTML頁面，不再控制前端的效果。
至於前端用戶看到什麼效果，從後端請求的數據如何載入到前端中，都由前端自己決定，網頁有網頁的處理方式，App有App的處理方式，但無論哪種前端，所需的數據基本相同，後端僅需開發一套邏輯對外提供數據即可。
在前後端分離的應用模式中，貴陽電腦培訓http://www.kmbdqn.cn/發現前端與後端的耦合度相對較低。
在前後端分離的應用模式中，我們通常將後端開發的每個視圖都稱為一個介面，或者API，前端通過訪問介面來對數據進行增刪改查。
② VB.Net 前後端分離怎麼實現的
1.一般來說，要實現前後端分離，前端就需要開啟一個本地的伺服器來運行自己的前端代碼，以此來模擬真實的線上環境，並且，也是為了更好的開發。因為你在實際開發中，你不可能要求每一個前端都去搭建一個java(php)環境，並且在java環境下開發，這對於前端來說，學習成本太高了。
?2.但如果本地沒有開啟伺服器的話，不僅無法模擬線上的環境，而且還面臨到了跨域的問題，因為你如果寫靜態的html頁面，直接在文件目錄下打開的話，你是無法發出ajax請求的(瀏覽器跨域的限制),因此，你需要在本地運行一個伺服器，可是又不想搭建陌生而龐大的java環境，怎麼辦法呢？nodejs正好解決了這個問題。在我們項目中，我們利用nodejs的express框架來開啟一個本地的伺服器，然後利用nodejs的一個http-proxy-middleware插件將客戶端發往nodejs的請求轉發給真正的伺服器，讓nodejs作為一個中間層。這樣，前端就可以無憂無慮的開發了
?3.由於前後端分離後，前端和後台同時開發時，就可能遇到前端已經開發好一個頁面了，可是卻等待後台API介面的情況。比如說A是負責前端，B是負責後台，A可能用了一周做好了基本的結構，並且需要API介面聯調後，才能繼續開發，
?4.而此時B卻還沒有實現好所需要的介面，這種情況，怎麼辦呢？在我們這個項目里，我們是通過了mock來提供一些假數據，我們先規定好了API介面，設計出了一套API文檔，然後我們就可以通過API文檔，利用mock來返回一些假數據，這樣就可以模擬發送API到接受響應的整一個過程，
?5.因此前端也不需要依賴於後端開發了，可以獨立開發，等到後台的API全部設計完之後，就可以比較快速的聯調。
③ Vue項目前後端分離下的前端鑒權方案
# Vue項目前後端分離下的前端鑒權方案
### 技術棧
前端Vue全家桶，後台.net。
### 需求分析
1. 前端路由鑒權，屏蔽地址欄入侵
2. 路由數據由後台管理，前端只按固定規則非同步載入路由
3. 許可權控制精確到每一個按鈕
4. 自動更新token
5. 同一個瀏覽器只能登錄一個賬號
### 前端方案
> 對於需求1、2、3，採用非同步載入路由方案
1. 首先編寫vue全局路由守衛
2. 排除登錄路由和無需鑒權路由
3. 登錄後請求拉取用戶菜單數據
4. 在vuex里處理菜單和路由匹配數據
5. 將在vuex里處理好的路由數據通過`addRoutes`非同步推入路由
```
router.beforeEach((to, from, next) => {
// 判斷當前用戶是否已拉取許可權菜單
if (store.state.sidebar.userRouter.length === 0) {
// 無菜單時拉取
getMenuRouter()
.then(res => {
let _menu = res.data.Data.ColumnDataList || [];
// if (res.data.Data.ColumnDataList.length > 0) {
// 整理菜單&路由數據
store.commit("setMenuRouter", _menu);
// 推入許可權路由列表
router.addRoutes(store.state.sidebar.userRouter);
next({...to, replace: true });
// }
})
.catch(err => {
// console.log(err);
// Message.error("伺服器連接失敗");
});
} else {
//當有用戶許可權的時候，說明所有可訪問路由已生成 如訪問沒許可權的菜單會自動進入404頁面
if (to.path == "/login") {
next({
name: "index"
});
} else {
next();
}
}
} else {
// 無登錄狀態時重定向至登錄 或可進入無需登錄狀態路徑
if (to.path == "/login" || to.meta.auth === 0) {
next();
} else {
next({
path: "/login"
});
}
}
});
```
##### 注意
> 我這里無需鑒權的路由直接寫在router文件夾下的index.js，通過路由元信息meta攜帶指定標識
```
{
path: "/err-404",
name: "err404",
meta: {
authentication: false
},
component: resolve => require(["../views/error/404.vue"], resolve)
},
```
> 上面說到路由是根據後台返回菜單數據根據一定規則生成，因此一些不是菜單，又需要登錄狀態的路由，我寫在router文件夾下的router.js里，在上面步驟4里處理後台返回菜單數據時，和處理好的菜單路由數據合並一同通過`addRoutes`推入。
這樣做會有一定的被地址欄入侵的風險,但是筆者這里大多是不太重要的路由，如果你要求咳咳，可以定一份字典來和後台介面配合精確載入每一個路由。
```
// 加入企業
{
path: "/join-company",
name: "join-company",
component: resolve => require([`@/views/index/join-company.vue`], resolve)
},
```
> 在vuex中將分配的菜單數據轉化為前端可用的路由數據，我是這樣做的：
管理系統在新增菜單時需要填寫一個頁面地址欄位`Url`,前端得到後台菜單數據後根據`Url`欄位來匹配路由載入的文件路徑，每個菜單一個文件夾的好處是：你可以在這里拆分js、css和此菜單私有組件等
```
menu.forEach(item => {
let routerItem = {
path: item.Url,
name: item.Id,
meta: {
auth: item.Children,
}, // 路由元信息 定義路由時即可攜帶的參數，可用來管理每個路由的按鈕操作許可權
component: resolve =>
require([`@/views${item.Url}/index.vue`], resolve) // 路由映射真實視圖路徑
};
routerBox.push(routerItem);
});
```
> 關於如何精確控制每一個按鈕我是這樣做的，將按鈕編碼放在路由元信息里，在當前路由下匹配來控制頁面上的按鈕是否創建。
菜單數據返回的都是多級結構，每個菜單下的子集就是當前菜單下的按鈕許可權碼數組，我把每個菜單下的按鈕放在此菜單的路由元信息`meta.auth`中。這樣作的好處是：按鈕許可權校驗只需匹配每個菜單路由元信息下的數據，這樣校驗池長度通常不會超過5個。
```
created() {
this.owner = this.$route.meta.auth.map(item => item.Code);
}
methods: {
matchingOwner(auth) {
return this.owner.some(item => item === auth);
}
}
```
> 需求4自動更新token，就是簡單的時間判斷，並在請求頭添加欄位來通知後台更新token並在頭部返回，前端接受到帶token的請求就直接更新token
```
// 在axios的請求攔截器中
let token = getSession(auth_code);
if (token) config.headers.auth = token;
if (tokenIsExpire(token)) {
// 判斷是否需要刷新jwt
config.headers.refreshtoken = true;
}
// 在axios的響應攔截器中
if (res.headers.auth) {
setSession(auth_code, res.headers.auth);
}
```
> 對於需求5的處理比較麻煩，要跨tab頁只能通過`cookie`或`local`,筆者這里不允許使用`cookie`因此採用的`localstorage`。通過打開的新頁面讀取`localstorage`內的`token`數據來同步多個頁面的賬號信息。`token`使用的`jwt`並前端md5加密。
這里需要注意一點是頁面切換要立即同步賬號信息。
> 經過需求5改造後的全局路由守衛是這樣的：
```
function _AUTH_() {
// 切換窗口時校驗賬號是否發生變化
window.addEventListener("visibilitychange", function() {
let Local_auth = getLocal(auth_code, true);
let Session_auth = getSession(auth_code);
if (document.hidden == false && Local_auth && Local_auth != Session_auth) {
setSession(auth_code, Local_auth, true);
router.go(0)
}
})
router.beforeEach((to, from, next) => {
// 判斷當前用戶是否已拉取許可權菜單
if (store.state.sidebar.userRouter.length === 0) {
// 無菜單時拉取
getMenuRouter()
.then(res => {
let _menu = res.data.Data.ColumnDataList || [];
// if (res.data.Data.ColumnDataList.length > 0) {
// 整理菜單&路由數據
store.commit("setMenuRouter", _menu);
// 推入許可權路由列表
router.addRoutes(store.state.sidebar.userRouter);
next({...to, replace: true });
// }
})
.catch(err => {
// console.log(err);
// Message.error("伺服器連接失敗");
});
} else {
//當有用戶許可權的時候，說明所有可訪問路由已生成 如訪問沒許可權的菜單會自動進入404頁面
if (to.path == "/login") {
next({
name: "index"
});
} else {
next();
}
}
} else {
// 無登錄狀態時重定向至登錄 或可進入無需登錄狀態路徑
if (to.path == "/login" || to.meta.auth === 0) {
next();
} else {
next({
path: "/login"
});
}
}
});
}
```
> 經過需求5改造後的axios的請求攔截器是這樣的，因為ie無法使用`visibilitychange`，並且嘗試網路其他屬性無效，因此在請求發出前做了粗暴處理：
```
if (ie瀏覽器) {
setLocal('_ie', Math.random())
let Local_auth = getLocal(auth_code, true);
let Session_auth = getSession(auth_code);
if (Local_auth && Local_auth != Session_auth) {
setSession(auth_code, Local_auth, true);
router.go(0)
return false
}
}
```
> 這里有一個小問題需要注意：因為用的`local`因此首次打開瀏覽器可能會有登錄已過期的提示，這里相信大家都能找到適合自己的處理方案
### 結語
經過這些簡單又好用的處理，一個基本滿足需求的前後端分離前端鑒權方案就誕生啦
④ 前後端分離，前端發送過來的請求是伺服器的ip還是用戶的ip
前後端分離部署時，伺服器A用於部署前端項目，稱為前端伺服器，伺服器B用於部署後端項目，稱為後端伺服器。後端伺服器通過開放API的方式，向前端伺服器中的前端項目提供數據或數據操作介面，以此實現前端與後端的銜接。若受項目的成本限制，將前端項目與後端項目部署在同一伺服器上也是可以的，可以通過nginx等反向代理伺服器根據訪問地址進行分發。
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全AJAX，使用Angular或者什麼什麼就可以了。
這個說法是不合適的，打個比方，別人問的是逗如何解決家禽把蛋生在水草邊的問題看地，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答逗不讓去水邊就行了地，這顯然不在點子上。
⑤ 前後端分離 前端請求url路徑怎麼處理
我認為是要比較嚴謹的，處理這個的話，你可以去後盾網哪裡找一下資源。
⑥ 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
⑦ 小程序怎麼製作前後端分離的分享模塊
創建一個前後端分離項目。
1、前端只需要獨立編寫客戶端代碼，後端也只需要獨立編寫服務端代碼提供數據介面即可。
2、前端通過Ajax請求來訪問後端的數據介面，將Model展示到View中即可。
3、前後端開發者只需要提前約定好介面文檔，然後分別獨立開發即可，前端可以造假數據進行測試，完全不需要依賴於後端，最後完成前後端集成即可，真正實現了前後端應用的解耦合，極大地提升了開發效率。
4、前端應用，負責數據展示和用戶交互。
5、後端應用，負責提供數據處理介面。
⑧ 怎麼理解前後端分離
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全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類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。