基於Abp React前端的專案建立與執行——React框架分析

JerryMouseLi發表於2021-01-27
React前端框架

基於Abp React前端的專案建立與執行

目錄

1 Abp專案配置

2 執行WebApi後端專案

2.1 建立C3D資料庫，並且將資料庫對應連結字串替換

2.2 建立資料庫進行資料遷移

主專案選擇到StartUp所在的專案，C3D.Web.Host,nuget console視窗打到C3D.EntityFrameWork.Core專案；

然後輸入資料遷移指令

Add-Migration first_init
Update-Database

2.3 執行WebApi專案

選擇C3D.Web.Host，點選執行。

Swagger WebApi 介面頁面如下：

3 執行React前端專案

3.1 利用yarn包安裝工具

利用yarn包安裝工具安裝react客戶端執行所需依賴包。

備註：會發現用npm無法安裝成功，用yarn包安裝時需要刪除package-lock.json檔案。

3.2 執行React專案

npm start

登入頁面

  • 登入使用者名稱:admin
    密碼：123qwe

  • dashboard

3.3 使用React客戶端的意義

有沒有感覺3.2的UI很好看，是的，個人感覺UI的精細程度已經遠遠超過VUE的Element 跟Iview UI了。因為該專案使用的是ant-design UI。

而 github上直接搜尋UI，按start排名。前兩個UI 的都是react。這也就是我選擇react的意義了。使用哪個框架其實都差不多，個人比較看重UI展示的精細化程度與美感。

這兩個UI框架的貢獻者與使用者規模已很大。

4 React 前端專案架構

4.1 技術棧

  • React 構建使用者UI的js庫；
  • Typescript 強型別語言，更適合後臺程式設計人員；
  • Mobx 簡單，可擴充套件的狀態管理框架；
  • AntDesign 可為企業應用程式提供更好的使用者體驗；

4.2 設計原則

SOLID

簡寫 全拼 中文翻譯
SRP The Single Responsibility Principle 單一責任原則
OCP The Open Closed Principle 開放封閉原則
LSP The Liskov Substitution Principle 里氏替換原則
ISP The Interface Segregation Principle 介面分離原則
DIP The Dependency Inversion Principle 依賴倒置原則

  • 單一責任原則：
    當需要修改某個類的時候原因有且只有一個（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。換句話說就是讓一個類只做一種型別責任，當這個類需要承當其他型別的責任的時候，就需要分解這個類。

  • 開放封閉原則：
    軟體實體應該是可擴充套件，而不可修改的。也就是說，對擴充套件是開放的，而對修改是封閉的。這個原則是諸多物件導向程式設計原則中最抽象、最難理解的一個。

  • 里氏替換原則：
    當一個子類的例項應該能夠替換任何其超類的例項時，它們之間才具有is-A關係。

  • 介面分離原則：
    不能強迫使用者去依賴那些他們不使用的介面。換句話說，使用多個專門的介面比使用單一的總介面總要好。

  • 依賴倒置原則：
    1.高層模組不應該依賴於低層模組，二者都應該依賴於抽象
    2.抽象不應該依賴於細節，細節應該依賴於抽象

4.3 mobx架構

官方例子

import React from "react"
import ReactDOM from "react-dom"
import { makeAutoObservable } from "mobx"
import { observer } from "mobx-react"

// Model the application state.
class Timer {
    secondsPassed = 0

    constructor() {
        makeAutoObservable(this)
    }

    increase() {
        this.secondsPassed += 1
    }

    reset() {
        this.secondsPassed = 0
    }
}

const myTimer = new Timer()

// Build a "user interface" that uses the observable state.
const TimerView = observer(({ timer }) => (
    <button onClick={() => timer.reset()}>Seconds passed: {timer.secondsPassed}</button>
))

ReactDOM.render(<TimerView timer={myTimer} />, document.body)

// Update the 'Seconds passed: X' text every second.
setInterval(() => {
    myTimer.increase()
}, 1000)

每個UI 元件（TimerView）都可定義一個observer 觀察者，無需強制繫結，一旦該元件值發生變化，則會對UI進行自動計算渲染。也即如下流程圖，一旦值變化事件發生，則會更新observer的狀態，進而計算，進而出發UI重新渲染，而定義好，這些都通過mobx自動完成。

4.4 React前端整體架構

  • 所有與後端通訊都通過服務層完成；
  • 每個容器裡的元件都會存在一個倉儲與一個模型；
  • 所有的服務在倉儲層被呼叫，而非元件層；元件會執行倉儲的actions來獲取最新狀態；
  • 展示元件的屬性可以直接儲存到倉儲中，也能直接去倉儲中取出；
  • 容器或者展示元件可以呼叫倉儲的actions，Mobx能直接將註冊過的元件進行自動渲染。

5 小結

這裡為什麼要用倉儲層呢，筆者根據自己理解解釋下，

  • 如果沒加倉儲，所有獲取後臺資料的服務都會洩漏到元件容器中，那樣萬一哪天需要改服務，則要到各元件中去改，會讓人抓狂，而該框架中只需要在倉儲層中改即可；
  • 另外有了倉儲層，比如vue的vuex與react的redux或者mobx，可以在倉儲層中作區分，而業務層程式碼完全可以寫成一樣，這樣更易於vue與react之間的移植；

這應該是屬於依賴倒置原則，元件呼叫依賴於倉儲這個抽象並沒有依賴於獲取資料的對應服務，從而實現了易擴充套件，易複用，易維護的目的。

版權宣告：本文為博主翻譯文章+自己理解，部分程式碼自己寫，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本宣告。 本文連結：https://www.cnblogs.com/JerryMouseLi/p/14336688.html

相關文章