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