後端開發者從零作一個移動應用（後端篇）

先來上一張前端頁面的效果圖（Vue + Vux + Vuex + Vue-Router）。

第一次作gif 沒什麼經驗，太大了。加載慢

項目地址： http://m.jiasux.com ，你們能夠自行手機打開查看效果。

---

好了，廢話少說，來聊聊後端

後端寫些什麼，什麼東西寫出來對我是更好的總結，也是對你們更好的幫助？在準備寫的時候，我思考了好久。

以前準備了 手摸手，嘴對嘴 教程。想想這樣子沒什麼意思，若是是一步步作的教程還不如看視頻去，就想也許經過總結後端結構（注意是結構不是架構）設計、代碼組織、模塊劃分對你們更有幫助。

後端開發的疑惑

後端開發最常面對的一個問題：性能、高併發等等。可是這不在本文的討論範圍，咱們只講基本的怎麼把代碼寫好，如何把業務模塊劃分好。

性能、高併發的解決方案， 大部分是在代碼以外的擴展。

那麼站在純粹的 寫代碼 角度，如何寫好後端的代碼呢？我之前的疑惑經常有：Controller 層到底放哪些代碼？Model 又能夠作哪些事情？本身的一些擴展、工具類，該如何組織？

發現如今可以想起的疑惑變少了，若是你有什麼疑惑，歡迎留言咱們一塊兒學習討論

雖然代碼主要是實現業務邏輯，可是選擇一款好的框架，很是有助於提高團隊做業能力，讓代碼層面的性能無憂。

框架的選擇

說實話，自感 php7 出來後，代碼層面的性能，已經到了一個很是高的層度。基本上在百萬級別左右的系統，在語言層面沒有什麼顧慮了。

框架方面，本身用過的php框架包括（時間前後）：ThinkPHP Laravel 非著名自造框架 Yii Phalcon

本文全部代碼結構設計與組織設計基於 Phalcon ，其它除了 自造框架 都是很是優秀的框架，不過框架層面的性能，就自身而言，是逐步升高。可是經過一些整合，也能夠逐步提高其自身性能，如：Laravel Yii與Swoole結合，也可達到 Phalcon 的程度。

php的版本是：7.1（若是你是一個新項目，必定要用php7）

後端要作些什麼

固然確定須要先把db設計好，不過這不在咱們討論範圍，假設已經完成了這一步。

咱們的代碼須要提供如下幾部分能力：命令行腳本、api版本、後臺管理這三部分。固然這三部分也能夠拆分紅三個項目，不太小公司、小項目沒有必要（放在一個項目，增強了代碼的複用性）

這三個是大的模塊，而後再一個個接下來分析。

命令行腳本

先說 命令行腳本 它是比較獨立的部分，不須要用戶調用，主要用來完成一些定時任務等。現代一點的框架，都提供這個模塊。
Phalcon提供了一個 CLI 模塊，能夠方便的完成這部分能力。他的代碼寫起來仍是 mvc 的結構，只不過訪問是經過命令行來進行。

好比一個最簡單的 cli

class MainTask extends Task
{
    public function mainAction()
    {
        return fwrite(\STDOUT, 'hello task!')
    }
}

api模塊

我在最先接觸api概念的時候，很懵逼，以爲很高大上。如今我對它的理解就是：先後端純數據通訊的一種方式。之前作web開發，咱們不提供api，直接後段把數據渲染在頁面上，用戶直接在渲染的界面上操做，而後經過按鈕或者什麼觸發一個請求到後端。

而到了api時代，在web方面有了先後端分離概念；移動app後端更是無力渲染（自然先後端分離）。因此要後臺須要把數據發給前端，前端根據數據的描述把數據用用戶看得懂的方式展示出來。好比一個商品的api可能結構以下：

{
    code: 1,
    msg: 'query ok',
    data: {
        name: '最涼快的空調',
        price: '9999.00',
        img: 'xxx.webp',
        stock: '10'
    }
}

這種方式讓先後端的開發彼此獨立，你們專一作本身的事情。可是這也帶來另一個問題：前端有了所謂的版本，後端必須兼顧全部使用的版本。若是咱們永遠只使用一個api地址。那麼代碼可能會至關難看。

好比如今有了一個新的需求，之前 空調 只有一張圖片。如今空調展現的時候有多張圖片。那麼有兩種辦法，一種是增長字段，一種是將原字段 img 變爲一個數組。

若是是增長字段不會帶來兼容性的問題。可是若是是粗暴的將img類型變動爲數組，以前的版本將沒法解析這個類型，所以要想變爲數組，只能是api的總體升級（通常不會由於這個問題就進行升級）。

那麼api作版本有哪些辦法呢？我採用了Phalcon的模塊來作api的版本控制。之前還嘗試過控制器版本。好比：
ApiV1Controller 表示這是v1版本。ApiV2Controller表示是v2版本。Phalcon的模塊爲版本提供了很是大的便利，直接新開一個模塊，取名 v1，若是以後要升級，新開一個模塊叫作 v2。對於不須要修改的功能，能夠簡單的讓v2控制器繼承v1中的控制器。

api的版本方面，咱們就能夠簡單經過url的方式完成，好比：

• https://api.xxx.com/v1/user/123

• https://api.xxx.com/v2/user/123
  版本信息就很是的一目瞭然。

後臺管理

絕大部分系統，都須要一個cms來上傳、修改相關資料。以加速俠爲例：須要上傳遊戲，須要編輯一些遊戲合輯等。你能夠單獨成一個項目，也能夠仍是用模塊來進行開發（我推薦，極大程度的提供了代碼複用）。

我最不能接受的一句話是：後臺順便弄一下，反正給公司內部用的。

作爲一個有追求的程序員，咱們必需要有底線，咱們的目標是：讓你們工做起來更便捷，更輕鬆，最後讓你們沒有工做（哈哈哈）。因此後臺我也建議採用先後端分離，經過Vue來進行開發。

當前的後臺使用了 Vue + Element UI + Vuex + Vue-Roter來進行開發。參考了，網絡上的： 手摸手，帶你用vue擼後臺，寫的真不錯，爲我學習省了不少彎路，特別是前端在權限控制上這一部分，他的方式讓我眼前一亮。個人後臺如今纔剛剛搭建完基本的部分（路由規劃、一些本身擴展的vue插件）

先後端分離後，後段其實也能夠歸結到api的開發部分。而且這樣帶來的一個好處是：若是之後後段要作移動版的一些功能，api都是現成的。

未完待續

寫代碼越久，愈加現語言層面的東西，只要多動手，很快就能達到一個水平。可是業務代碼寫的再多，也不能讓你再技術領域走的更遠。所以若是你有幸在大公司，有機會接觸大型項目（百萬、千萬用戶級）的，必定好好觀察爲了這個項目這麼多人開發，還可以很好的運做？他是如何解耦業務邏輯與系統架構？若是是在小的公司，那麼就儘量本身嘗試去作一些系統的搭建，讓你們在這個基礎上進行業務開發，而不須要關心一些底層的東西，一個新手也能很快上手寫業務。

後面可能還會有兩篇到四篇講後端部分。主要包括，後端項目結構的劃分（這個結構我已經嘗試過在三、4個項目中使用，目前都運行的很好），後端登錄控制（會開源一個Phalcon的oauth2的代碼），後段api的自動化測試。

相關代碼我將會陸續放在github上面。全部的代碼就叫 x- 吧。x 從小學數學給我留下了深入印象。

• x-api 是php的後端項目

• x-control 是vue寫的後端管理系統

• x-client 是vue系的客戶端界面

---

我的博客：https://helei112g.github.io/