基於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