大家都知道，通常公司都會要求我們前端和後端分開來寫，為什麼要這麼做呢？這次帶給大家前後端為什麼要分開寫，下面就是實戰案例，一起來看一下。
如果你沒有嘗試過前後端分離的工作流程，那麼可以先試想一下這樣的流程改變：
把流程從
PM：「我想要這個功能」
後端：「這個先找前端做個模板」
前端：「模板做完了」
後端：「我來對接一下，這裡樣式不對」
前端：「我改完了」
後端：「功能交付」
PM：「春節要加這個活動」
後端：「這個先找前端改個模板」
前端：「模板做完了」
後端：「我來對接一下，這裡樣式不對」
前端：「我改完了」
後端：「功能交付」
變成
PM：「我要這個功能」
前端：「我要介面」
後端：「介面完成了」
前端：「我來對接一下，功能交付」
PM：「春節要加這個活動」
前端：「需要增加介面」
後端：「介面完成了」
前端：「我來對接一下，功能交付」
由此可見，前後端分離的主要概念就是：後台只要提供API介面，前端呼叫AJAX實作資料呈現。
現狀與分歧
身為前端開發人員，我們應該嘗試一些新穎的技術，完善每一個細節性的問題，不斷突破自我。雖然前後端分離已經算不上什麼新穎的技術或思路，但是目前很多後台開發人員甚至前端開發人員都沒有接觸過。
據我個人的了解，如果在一個部門裡，部門人員全是後台開發人員，前端的一些頁面也是由後台人員完成的，那麼前後端分離對於他們而言可能是一片未知的領域，專案大多是前後端強耦合的，甚至不存在前端的概念。
在不重視前端的公司或部門，不了解前後端分離這也無可厚非。大多的創業型公司，一個部門就一兩個前端，而且一人負責幾個項目，很少有合作完成一個專案的時候。因為沒有什麼標準可言（這裡的標準指的是程式碼組織架構），所以就是前端人員切好圖寫好頁面丟給後端，以後端程式碼結構為標準。雖然有些公司有前後端分離的意識，但都不知該如何實踐。在那時，部門的後台人員認為前後端分離就是後台不再需要寫HTML和JS了，可以交給前端來做了，然而這只能叫做前後端分工。
以上講述的是一種情況: 不了解前後端分離，也不知如何去實踐的。下面還有一種情況：了解前後端分離，但不想嘗試的。
針對第二種情況，很多人也做過相應的解釋，其實這就牽涉到「前後端分離的利弊」問題。很多後台人員會認為自己所做的那一套沒有問題，即便後台套用前端html也是司空見慣，一直是大勢所趨，後台MVC框架也是這麼推薦使用的，很合理。這時候前端開發人員在部門中的話語權往往是不夠的，或是認為後台開發人員的意見永遠是對的，沒有主觀性。
相反，也有可能是後台開發人員非常推薦前後端分離，而前端開發人員不想去實踐的。這時候前端會認為後台開發人員在瞎折騰，之前前後端不分離專案做起來都很順利，分離了反而會給自己帶來額外的工作量和學習成本，而這就取決於前端的技術能力和見識了。
當然，這也是我個人認為的前後端分離所存在的一些現狀和分歧所在。
場景與要求
對於前後端分離的應用場景，不是所有的場景都適合，但是大多數專案都能夠透過前後端分離來實現。
由於我主要從事企業級後台應用的前端開發工作，個人認為對於後台應用的開發來說，前後端分離帶來的利是遠大於弊的。
大多數後台應用程式我們都可以做成SPA應用（單頁應用），而單頁應用最主要的特點就是局部刷新，這透過前端控制路由呼叫AJAX，後台提供介面便可以實現，而且這樣的方式使用者體驗更加友好，網頁載入更加快速，開發和維護成本也降低了不少，效率明顯提升。
同樣的，在展示類網站和行動APP頁面中前後端分離也同樣試用。前後端不分離的情況下，服務端要單獨針對Web端做處理，返回完整HTML，這樣勢必增加服務端的複雜度，可維護性差，而web端需要載入完整的HTML，一定程度上影響網頁效能，這對於行動端性能為王的地方非常的不友善。
隨著前端技術的發展與迭代，前端MVC框架應運而生，利用目前主流的前端框架，如React、Vue、Angular等我們可以輕鬆的構建起一個無需伺服器端渲染就可以展示的網站，同時這類框架都提供了前端路由功能，後台可以不再控制路由的跳轉，將原本屬於前端的業務邏輯全部丟給前端，這樣前後端分離可以說是最為徹底。以下是一段前端控制路由的程式碼：
'use strict'export default function (router) {
router.map({ '/': { component: function (resolve) { require(['./PC.vue'], resolve)
}
}, '/m/:params': { component: function (resolve) { require(['./Mobile.vue'], resolve)
}
}, '/p': { component: function (resolve) { require(['./PC.vue'], resolve)
}, subRoutes: { '/process/:username': { component: function (resolve) { require(['./components/Process.vue'], resolve)
}
}
}
}
})
}登入後複製
前後端分離的實作對技術人員尤其是前端人員的要求會上升一個層次，前端的工作不只是切頁面寫模板或是處理一些簡單的js邏輯，前端需要處理伺服器傳回的各種資料格式，還需要掌握一系列的資料處理邏輯、MVC想法和各種主流框架。
優勢與意義
對於前後端分離的意義我們也可以看做是前端渲染的意義，我主要總結了下面四點：
徹底解放前端
前端不再需要向後台提供模板或是後台在前端html中嵌入後台程式碼，如：
<!--服务器端渲染 --><select>
<option value=''>--请选择所属业务--</option>
{% for p in p_list %} <option value="{{ p }}">{{ p }}</option>
{% endfor %}</select>登入後複製
這是前後端耦合的，可讀性差。
<!--前端渲染 --><template>
<select id="rander">
<option value=''>--请选择所属业务--</option>
<option v-for="list in lists" :value="list" v-text="list"></option>
</select></template><script>export default { data: { return { lists: ['选项一', '选项二', '选项三', '选项四']
}
}，
ready: function () { this.$http({ url: '/demo/', method: 'POST',
})
.then(function (response) { this.lists = response.data.lists // 获取服务器端数据并渲染
})
}
}
</script>登入後複製
上面是前端渲染的一段程式碼，前端透過AJAX呼叫後台接口，資料邏輯放在前端，由前端維護。
提高工作效率，分工更明確
前後端分離的工作流程可以讓前端只專注於前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將資料寫死或呼叫本地的json檔案即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
局部效能提升
透過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面互動及使用者體驗上有所提升。
降低維護成本
透過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，程式碼重構及可維護性增強。
心得與體會：
一路走來，專案一個接著一個，從一開始的後台控制路由、後台渲染頁面到現在的前端控制路由、前端渲染數據，工作流程和方式都發生了很大的變化。每當遇到下面情形的時候，我都會為前後端分離帶來的優勢而感慨一番：
1、專案一開始製作前端頁面的時候，我不再需要後台給我設定伺服器環境了
2、專案的前端檔案可以在需要呼叫後台介面的時候丟進伺服器就好了，完全不需要事先放進去
3、增加一個專案頁面需要設定路由的時候不再需要讓後台同事給我加了，自己前端搞定
4、前端文件裡不再摻雜後台的代碼邏輯了，看起來舒服多了
5、頁面跳轉比之前更加流暢了，局部渲染局部載入非常快速
6、頁面模板可以重複使用了，前端元件化開發提高了開發效率
等等。面對快速發展的前端，我們應該去適應其帶來的工作方式和流程的改變，目前的前後端分離的工作方式必然是今後的趨勢所在，作為一個前端開發人員，我們應當承擔這個普及前端新知識和改變現狀的責任。
相信看了本文案例你已經掌握了方法，更多精彩請關注php中文網其它相關文章！
相關閱讀：
Angularjs如何實作mvvm式選項卡？案例+代碼
vue2.0的專案非常實用的程式碼集合
以上是前後端為什麼要分開寫的詳細內容。更多資訊請關注PHP中文網其他相關文章！
