架構 Roadmap 筆記分享

雖然咱們的架構不是開源的，不過一些筆記能夠願意公開和你們討論一下，我相信很多人在和咱們幹着一樣的事情，那不如一起交流一下，這樣咱們能夠更快。

 

這裏前端，後端都有，前端咱們用的是 avalon js，基本無坑，推薦下。

 

混合應用，*APP 版本熱更新支持。

混合應用，*如今將微信 Web APP 切換到 本地 APP 還須要一些手動的替換工做，架構上能夠持續優化。

混合應用，*目前 APP 的頁面切換效果很生硬，加入相似 iOS 的左側滑動返回切換動畫，以及頁面跳轉的動畫。

混合應用，結合調用本地硬件場景 Demo。

 

這個後端的：

底層架構，*加強 IoC 依賴注入，更完全的模塊化，Repository Session 生命週期優化

底層架構，*Command / Query 分離，Service 簡化

底層架構，*EventBus 增長 Context Parameter 支持

底層架構，*框架已經具備分佈式處理的理論模型和基礎層面支持，有須要時可實現分佈式處理（基於事件和事件路由分發）

底層架構，*管理後臺前臺分離成兩個網站。

底層架構，*支持多個數據庫鏈接。

底層架構，*負載均衡（因爲一些如系統配置、權限矩陣信息是緩存在內存裏的，進行一些改動能支持多臺機器負載均衡，5 人天）

底層架構，*支持多種技術混合，經過支持 js 借力 nodejs，經過支持 java 借力 java 開源項目

底層架構，*提供代碼熱更新，經過與 VS 集成，重編譯模塊時，框架檢測到若是隻是修改了 Controller ，則直接將現有 AppDomain 中的 Controller 映射替換，而不是重啓，節省 Web 開發時反覆修改，啓動的時間損耗。同理，這一步實現後，由於未來 Repository、Service 的引用是經過 IoC 動態獲取的，更新 IoC 中類型的引用映射，因此能夠將這種類型映射熱替換的模式應用到 Repository 和 Service 層去，從而很大程度減小開發時須要從新啓動的次數

底層架構，*一個程序多個數據庫鏈接支持。

 

 

基礎設施，*優化快速查詢 API，設計一種小型架構，支持根據約定就能搞定 Web Api（Query 條件、SELECT Projections、分頁）

基礎設施，*針對優化互聯網類應用作架構優化，主要是簡化、加速、清晰開發過程，目前架構應對互聯網類型的問題是，JSON 查詢，View 返回，POST 提交動做處理，都在 Controller Action 裏面，新的架構要更簡化更清晰這個結構，Command 和 Query 應分離，更快，同時抽象度和可複用度要更好

基礎設施，*多態分頁 model&API 優化，同時支持 page，pageSize 和 skipCount，takeCount 兩種分頁風格，實現一套 API 適應不一樣應用場景

基礎設施，*Framework Console 提供小工具，如：工程師輸入一個 url ，返回出是那個 Controller，Class 類名，那個 dll，最好能反應出代碼路徑，而後點擊一下就能打開那個代碼文件，項目大了不用在去 VS 裏面一個個打開文件夾尋找。

 　　

架構應該在設計上體現一種開闊接納的胸懷，各類東西均可以接入進來，對於應用層的東西，不要有潔癖。