從壹開始先後端分離 [ Vue2.0+.NET Core2.1] 十四 ║ VUE 計劃書 & 個人先後端開發簡史

時間 2019-11-05

標籤開始後端分離 vue2.0+.net vue core2.1 core 十四計劃書個人開發簡史简体版

原文原文鏈接

---新內容開始---javascript

番外

你們週一好呀，又是元氣滿滿的一個週一呀！感謝你們在週一這個着急改Bug的黃金時期，抽出時間來看個人博文哈哈哈，時間真快，已經到第十四篇博文了，也很順順（跌跌）利利（撞撞）的來到了Vue的講解，羣裏有小夥伴說，感受後端還有不少沒有更新，是呀！仍是有不少東西的在後端，只不過想把vue給簡單的搭建出來，若是你們有後端的一些知識，能夠給我留言，我總結後，在Vue系列以後再繼續說，再強調一次，後端之後還會更新。css

前邊的.net core 文章我會一直在更新中，一直在修改其中的錯誤，或者不是很清晰的地方，或者你們提出的問題，我都會放進去（由於如今開始了Vue，有的小夥伴在看.Net Core 的時候遇到問題歡迎來羣裏，實時給你們解決問題）。你們若是看的時候，可能在文中會不經意間看到本身的名字，這裏統一說一下，若是你指出了個人錯誤，或者提出了建設性的建議，我會把您的相關問題放到文中，算是一種鼓勵支持個人動力？(要是感受不適合，能夠私信給我，或者咱的QQ羣，我去掉)。週末的時候我聽取了@高海東的意見，把代碼升級到了.Net Core 2.1版本，如今的Git項目裏已經被2.1版本的覆蓋了，其實基本上都差很少，只是在Swagger那部分會有一些輕微的不一樣，我也把2.0版本的放到了Git新地址，https://github.com/anjoy8/Blog.Core2.0 須要2.0版本的能夠去下載。html

前言

好啦，開始今天的講解，今天呢，你們能夠不用關心Git，或者各類Code了，由於今天不涉及到代碼，今天主要說的是個人開發經歷，而後說明下互聯網BS開發下的Web發展史，而後引出VUE——一個先後端分離的較好的前端框架（目前前端三大框架React、Vue、Angular）。你們能夠簡單看一下，不管你是作BS開發的，仍是CS開發的。前端

本VUE系列我大概有如下幾個路線系列（可能之後有增刪），內容可能涉及的有些多，由於要從頭開始講，若是你感受是後端不必學習的話，權當是個樂子了，能夠看看，由於我不是專業講師，你們看看對知識點混個臉熟就行，知道有這回事兒，怎麼用，萬一下一個項目要用到呢，是吧。若是你想好好了解下，或者想轉前端（全棧，我也在去全棧的路上），能夠試一試，本身之後跟着練習下：vue

強調一點：如今的前端已經不是之前那種單純的切圖片，畫頁面了，前端框架層出不窮，面向對象寫法的要求日益增長，邏輯性的呼聲愈來愈高，因此個人感受就是，如今的前端已經往全棧方向發展，後端往架構師方向發展。java

一、Web開發經歷哪些時期node

二、JS高級開發 —— 面向對象系列和 ES6（若是想了解js初級，能夠單找我。）react

三、vue開篇，引入vue.js，基本指令語法系列webpack

四、Vue生命週期系列ios

五、搭建腳手架Vue-cli，安裝node.js，npm基礎系列

六、Axios訪問.Net Core Api相關

七、模板-事件屬性-修飾符等

八、webpack打包相關

九、Vue-router路由相關

十、組件詳解系列

十一、Vuex狀態模型庫系列

十二、SSR 服務端渲染，Nuxt.js 項目二講解

系列包含的知識點大概是這些：

零、今天要實現紅色的部分

注意：如下這只是我我的的經歷以及思考，不是百度正版的，有不一樣意見請提出來

先上一個網絡截圖，很簡單

1、簡潔明快的單頁面時代——沒有先後端的ASP

一、背景

我接觸到的第一個項目，那時候還在大學，就是Asp項目，仍是當地政府的，當時第一次用到，感受真的很神奇，經過代碼的敲寫，就能動態的展現出來，還能鏈接數據庫持久化，這麼多年過去了，如今再從新看，感受看到頭都大了，從網上下載了一套源碼，你們能夠簡單看看，真的神奇，不只html代碼裏有邏輯代碼，還有sql鏈接數據庫，嗯。。。可能部分讀者都沒有接觸過這樣的代碼了，不過雖然看着很凌亂，可是在瀏覽器渲染生成了Html頁面，仍是和普通的asp.net mvc是同樣的樣式

二、代碼樣式

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <%'include此行代碼供安裝插件用勿刪改%>
    <% Const funpath = "../" Const dbpath = "../" Set ctr_page = New tr_page
    Set ctr_user = New tr_user
    Set ctr_comment = New tr_comment %>
    <%pageno = tr_killstr(request.querystring("pageno"), 1, 8, 1, "", "", "", "", 1) %>
    <%'head此行代碼供安裝插件用勿刪改%>
    <title>反饋留言_<%=application(siternd & "55trsitetitle")%></title>
    <link rel="shortcut icon" type="image/x-icon" href="<%=funpath%>favicon.ico"
    <%'headend此行代碼供安裝插件用勿刪改%>
</head>
<body>
    <%'body1此行代碼供安裝插件用勿刪改%>
    <%if application(siternd & "55tropenguestbook")=1 then%>
    <div class="alert alert-warning alert-dismissible trnotice1" role="alert">
        <button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button>

        <%=application(siternd & "55trguestnotice")%>
    </div>
    <form id="form1" name="form1" method="post" action="usersave.asp" target="ifr1" onSubmit="return checkguest(this)">
        <%'body5此行代碼供安裝插件用勿刪改%>
        <table class="trsendtb">
        <tr>
        <td align="center" colspan="11"><textarea id="content" name="content" class="trgcontent trinput6"></textarea></td>
        </tr>
        <%'body6此行代碼供安裝插件用勿刪改%>
        <tr>
        <td align="left"><img id="codeimg" src="../core/Code.asp?rd=" style="cursor:hand; " title="點擊更換" onClick="javascript: this.src = '../core/Code.asp?rd=' + randomString(10) + ''" height="24" border="0" width="70"></td>
        <td align="right">
        <input type="submit" value="當即提交" name="submit1" id="submit1" class="trbt3 trmar1" />
        <input type="hidden" value="guest" name="action" />
        </td>
        </tr>
        <%'body7此行代碼供安裝插件用勿刪改%>
        </table>
        <%'body8此行代碼供安裝插件用勿刪改%>
    </form>
    <table align="center" border="0" cellpadding="3" cellspacing="1" id="mytable" class="trtable2">
    <% sql = "select id,username,content,addtime,homepage,asuser,answer,astime from tr_comment where types=2 and ispass=1 and isdel=0 order by addtime desc , id desc " page_size = 20 pagei = 0 n = (pageno -1) * page_size
    Call ctr_page.create_rs(sql, rs, conn, page_size, pageno) ' rs.open sql,conn,0,1
    If Not rs.EOF Then
    Do While Not rs.EOF ' and pagei
    <page_size If pagei>
    = page_size Then Exit Do
    pagei = pagei + 1 n = n + 1
    %>
    <p class="trp1">
    <span class="uname">
    <%if trim(rs("homepage"))<>"" then%>
    <%if isweburl(rs("homepage")) then%>
    <a href="#"><%=rs("username")%></a>
    <%else%>
    <%=rs("username")%>
    <%end if%>
    <%else%>
    <%=rs("username")%>
    <%end if%>
    </span> 說： <%=rs("content")%>
    </p>
    <div class="col-lg-3 <%=colbs3%> trrow1199 trlistright trovh" id="trlistright178888">
    <%'body3此行代碼供安裝插件用勿刪改%>
    </div>
    </div>
    <div class="trpublicline clearfix "> </div>
</body>
</html>

三、概要講解

這就是Web 1.0 時代，典型的就是ASP，在以前web開發中，也是獨領風騷了一段時間，適合小項目，不分先後端，你們一塊兒開發頁面，那個時候你們是按照頁面來分工的，寫好的頁面直接就能夠跑，不須要編譯，有點兒像PHP，服務端給什麼瀏覽器就展示什麼，展示的控制在 Web Server 層。

優勢：

一、無需編譯，可在服務器端直接執行。

二、容易編寫，可以使用普通的文本編輯器編寫，如記事本就能夠完成

三、由腳本在服務器上而不是客戶端運行，用戶端的瀏覽器不須要提供任何別的支持，這樣大大提升了用戶與服務器之間的交互速度。

缺點：

一、代碼邏輯混亂，難於管理：因爲ASP是腳本語言混合html編程，因此你很難看清代碼的邏輯關係，而且隨着程序的複雜性增長，甚至超出一個程序員所能達到的管理能力，各類問題就出現了。

二、代碼的可重用性差：因爲是面向結構的編程方式，而且混合html，因此可能頁面原型修改一點，整個程序都須要修改，更別提代碼重用了。

三、弱類型形成潛在的出錯可能：只支持兩種非類型的語言：VBScript和JavaScript，儘管弱數據類型的編程語言使用起來回方便一些，但相對於它所形成的出錯概率是遠遠得不償失的。

四、缺少完善的糾錯/調試功能。

這個時期發展到了後端，真是苦不堪言，爲了讓先後端分工更合理高效，提升代碼的可維護性，Asp.Net MVC框架就出現了。

注：其實以後是aspx，也就是asp.net Webfrom開發，第一次把先後端代碼摘開，這裏就不詳細說了。

2、先後端開始分工的時代——MVC

一、背景

我是前端起家的，而後轉向後端的，當2014年接觸MVC的時候，就深深的被吸引了，感受這種整齊的，分工明確的感受，讓我耳目一新，今後就開始了後端程序員之路。當時開發的是公司的一個企業內部管理系統，是一箇中型的項目，地址就不說了。

二、源代碼就不粘貼了

注意：這裏我要說一下，我曾經看到一個朋友本身寫公司框架，是把Controller和Views放到了兩個層裏邊，嗯，就好像把Model層提出了同樣，這三個都提出來了，這也是一個思路。

三、概要講解

優勢：

一、較好的解決了單頁面開發，或者單純的Code behind的aspx開發中所出現的問題

二、代碼可維護性獲得明顯好轉，每一個部分都有本身的應該負責的職能。

三、爲了讓 View 層更簡單強大，還能夠選擇aspx或者Razor模板，甚至能夠在裏邊書寫C#代碼。

缺點：

一、前端開發重度依賴開發環境。在這種模式下，前端寫 demo，寫好後，讓後端去套模板，有可能套錯，套完後還須要前端肯定，來回溝通調整的成本比較大。有時候爲了一個前端樣式，須要後端去從新編譯（ eg.由後端動態生成前端樣式的狀況）。

二、整個開發過程當中，不只僅是前端和後端相互依賴，後端控制器和model的糾纏不清，各類剪不斷理還亂，有時候爲了處理邏輯而修改model，有時候修了model還要多處屢次修改controller，個人天，想一想都累心喲，不過咱們卻都是這麼作的 [哭笑]。

注：固然說的有些誇張，目前MVC模式仍是很好的一種框架模式。

3、異步出現 ——AJAX，前端小時代

一、背景

還記得第一次使用異步編程是在2015年，當時使用的時候，真是整我的都開心壞了，頁面不用再刷新，點擊跳轉，點擊提交，點擊分頁，點擊任何地方，都是局部加載，感受整我的都很輕鬆，這個時候我也由一個完徹底全的後端，開始慢慢接觸前端，開始寫HTML代碼，開始寫CSS，仍是用Jquery來寫各類接口請求，各類拼接頁面DOM，各類頁面交互動做等等。開始往前端邁進。

二、代碼，簡單的一個，基於面向對象的寫法

    function(options) {
        options = .extend({ odd: 'odd', even: 'even', selected: 'selected' }, options); ('tbody>tr:odd', this).addClass(options.odd);
        ('tbody>tr:even', this).addClass(options.even); ('tbody>tr', this).click(function () {
            var hasSelected = (this).hasClass(options.selected); (this)hasSelected ? 'removeClass' : 'addClass'
                .find(':checkbox').attr('checked', !hasSelected)
        })

        $('tbody>tr:has(:checked)', this).addClass(options.selected); return this //返回this , 使方法可鏈
    }

})
}) (jQuery);
    $(function () { // $('.red').color('blue');

        $('#table2').alertBgColor({ odd: '', even: 'even', selected: 'selected' }).find('th').css('color', 'green')

    })

三、概要講解

優勢

一、先後端的分工很是清晰，先後端的關鍵協做點是 Ajax 接口

二、前端能夠自由的開發了，不受後端開發環境的過度約束

缺點

一、前端過度依賴接口開發。若是後端的接口不規範，亂寫，業務邏輯不穩定，那麼前端開發會很痛苦。爲了解決這個問題，RESTful接口規範就出現了，還記得麼，我們在.Net Core api框架中使用的。有了和後端一塊兒沉澱的接口規則，還能夠用來模擬數據，使得先後端能夠在約定接口後實現高效並行開發。相信這一塊會越作越好。

二、前端開發的複雜度控制。這個我深有體會，在這兩年，我有時候開發接口，有時候作前端頁面渲染，有時候還要增長特效，過度的操做DOM，真是讓人力不從心，幾乎每個頁面依賴的JS代碼都有上千行代，前端頁面渲染愈來愈慢，愈來愈笨重，還記得上次面試的時候，被問到了如何前端優化，嗯~~~都是淚。

三、在Json返回的數據量比較大的狀況下，渲染的十分緩慢，會出現頁面卡頓的狀況，並且資源消耗嚴重，在業務複雜的狀況下，一個頁面可能要發起屢次HTTP請求才能將頁面渲染完畢。

四、這種仍是屬於辦分離，爲何說是半分離的？由於不是全部頁面都是單頁面應用，在多頁面應用的狀況下，前端由於沒有掌握controller層，前端須要跟後端討論，咱們這個頁面是要同步輸出呢，仍是異步Json渲染呢？並且，即便在這一時期，一般也是一個工程師搞定先後端全部工做。所以，在這一階段，只能算半分離。

4、先後端分離 ——ＭＶ** 時代

一、背景

今天，全棧這個時代正在到來，或者已經日益成熟，只不過很遺憾的是，我尚未來的及開發過這種真正的先後端框架（還好的是我負責過公司的幾個微信小程序項目），所以只能本身動手了，一方面知足本身的須要，另外一方面也幫助一部分和我同樣學習的，或者從後端轉前端的小可愛們。

不過仍是有不少人不喜歡，或者不想弄懂這個先後端分離技術

二、代碼

是一種全新的體驗，組件模塊的趨勢

<template>//模板樣式 V
    <el-menu
            :default-active="activeIndex2"
            class="el-menu-demo"
            mode="horizontal"
            @select="handleSelect"
            background-color="#545c64"
            text-color="#fff"
            :router="true"
            active-text-color="#ffd04b">
        <el-menu-item index="/">
            <span class="el-icon-menu"></span>
            MMP Jobmonitor
            <sup>Beta</sup>
        </el-menu-item>
        <el-menu-item index="/a">WatchLists</el-menu-item>
        <el-menu-item index="/b">Jobs</el-menu-item>
        <el-menu-item class="user-info" index="">
            <img id="headImg" src="http://who/Photos/a.jpg" padding="0" margin="0" width="40">
            Hi,MM Team User
        </el-menu-item>
    </el-menu>
</template>

<script>//腳本信息 MV
    export default {
        data() {
            return {
                activeIndex2: '/'
            };
        },
        beforeCreate() {
            let pathIndex = this.$route.path;
            this.activeIndex2 = pathIndex;
            console.log(this.activeIndex2);
        },
        methods: {
            handleSelect(key, keyPath) {
                console.log(key, keyPath);
            }
        }
    }
</script>

<style scoped>//樣式
    sup {
        top: -0.6em;
        position: relative;
        vertical-align: baseline;
    }

    .user-info {
        float: right !important;
    }
</style>

三、概要說明

優勢

一、分層開發，職責劃分更清晰，nodejs做爲前端服務器，由前端開發人員負責，前端開發人員不須要知道C#後臺是如何實現的，也不須要知道API接口是如何實現的，咱們只須要關心咱們前端的開發工做，而且管理好nodejs前端服務器，然後臺開發人員也不須要考慮如何前端是如何部署的，他只須要作好本身擅長的部分，提供好API接口就能夠；

注意：這裏可能有歧義，感謝@SoarNo1的提醒，應該是這裏吧。是開發的過程當中，前程工程師在本地搭建vue+node環境，開發後發佈的時候，已經不依賴Node了。

二、獨特的異步、非阻塞I/O的特色，這也就意味着他特別適合I/O密集型操做，在處理併發量比較大的請求上能力比較強，所以，利用它來充當前端服務器，向客戶端提供靜態文件以及響應客戶端的請求，我以爲這是一個很不錯的選擇。

三、適配性提高；咱們其實在開發過程當中，常常會給PC端、mobile、app端各自研發一套前端。其實對於這三端來講，大部分端業務邏輯是同樣的。惟一區別就是交互展示邏輯不一樣。若是controller層在後端手裏，後端爲了這些不一樣端頁面展現邏輯，本身維護這些controller，模版沒法重用，徒增和前端溝通端成本。

四、性能獲得提高；你們應該都知道單一職責原則。從該角度來看，咱們，請求一個頁面，可能要響應不少個後端接口，請求變多了，天然速度就變慢了，這種現象在mobile端更加嚴重。採用node做爲中間層，將頁面所須要的多個後端數據，直接在內網階段就拼裝好，再統一返回給前端，會獲得更好的性能

----------------- 這裏有網上其餘網友的總結，也不錯 --------------------

一、能夠實現真正的先後端解耦，前端服務器使用nginx。前端/WEB服務器放的是css，js，圖片等等一系列靜態資源（甚至你還能夠css，js，圖片等資源放到特定的文件服務器，例如阿里雲的oss，並使用cdn加速），前端服務器負責控制頁面引用&跳轉&路由，前端頁面異步調用後端的接口，後端/應用服務器使用tomcat（把tomcat想象成一個數據提供者），加快總體響應速度。（這裏須要使用一些前端工程化的框架好比nodejs，react，router，react，redux，webpack）

二、發現bug，能夠快速定位是誰的問題，不會出現互相踢皮球的現象。頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，所有由前端工程師來負責。接口數據出錯，數據沒有提交成功，應答超時等問題，所有由後端工程師來解決。雙方互不干擾，前端與後端是相親相愛的一家人。

三、在大併發狀況下，我能夠同時水平擴展先後端服務器，好比淘寶的一個首頁就須要2000+臺前端服務器作集羣來抗住日均多少億+的日均pv。（去參加阿里的技術峯會，聽他們說他們的web容器都是本身寫的，就算他單實例抗10萬http併發，2000臺是2億http併發，而且他們還能夠根據預知洪峯來無限拓展，很恐怖，就一個首頁。。。）

四、減小後端服務器的併發/負載壓力。除了接口之外的其餘全部http請求所有轉移到前端nginx上，接口的請求調用tomcat，參考nginx反向代理tomcat。且除了第一次頁面請求外，瀏覽器會大量調用本地緩存。

五、即便後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。

六、也許你也須要有微信相關的輕應用，那樣你的接口徹底能夠共用，若是也有app相關的服務，那麼只要經過一些代碼重構，也能夠大量複用接口，提高效率。（多端應用）

七、頁面顯示的東西再多也不怕，由於是異步加載。

八、nginx支持頁面熱部署，不用重啓服務器，前端升級更無縫。

九、增長代碼的維護性&易讀性（先後端耦在一塊兒的代碼讀起來至關費勁）。

十、提高開發效率，由於能夠先後端並行開發，而不是像之前的強依賴。

十一、在nginx中部署證書，外網使用https訪問，而且只開放443和80端口，其餘端口一概關閉（防止黑客端口掃描），內網使用http，性能和安全都有保障。

十二、前端大量的組件代碼得以複用，組件化，提高開發效率，抽出來！