開發框架幫大家整體項目結構都搭建好了，也可以直接運行了 從登錄到打開主工作區 到菜單展示： 一般的項目就沒有任何問題了。 大家都知道班級不可能只有一班，那還有二班、三班呢 二班、三班是什麼鬼，我們統稱不一般 我們只要解決了 （一班 + 非一班）的問題 那就解決了所有問題了，100%不留死角了。 言歸 ...
開發框架幫大家整體項目結構都搭建好了，也可以直接運行了
從登錄到打開主工作區
到菜單展示：
一般的項目就沒有任何問題了。
大家都知道班級不可能只有一班，那還有二班、三班呢
二班、三班是什麼鬼，我們統稱不一般
我們只要解決了 （一班 + 非一班）的問題 那就解決了所有問題了，100%不留死角了。
言歸正傳：
例如框架裡面的登錄，肯定是標準的登錄，通過公司統一許可權平臺
登錄成功後，Session有 LoginNo UserName CompanyCode CompanyName等基本信息
這個時候，作為具體的某個業務系統，可能這些只是基本的信息，那還有特殊的。
比如，舉例子：WMS系統 用戶是綁定到 某個 倉庫的，一旦登錄這個倉庫就 通過用戶ID 就知道了，存儲到Session這樣到後續的畫面都預設是這個倉庫，都不用選，也不可以選。
那框架怎麼應對來自項目的個性化內容了，
每個都給考慮 做了，那麼不對的，事實上也做不來，業務的事情就應該交給業務系統搞定。
框架只要提供相應的靈活介面，實現二者的協同即可。
靠什麼協同：
如下 WMSWebApp
在這個類裡面 覆寫 Login方法，方法內容業務系統自己根據實際的需要實現自己的邏輯
可以了，這樣就可以了。
可以更好奇一點，框架怎麼知道 WMSWebApp這個類的存在的
要適當的弄清楚系統運行的來龍去脈：
這樣就會更好的理解框架：
正如上圖所示：在 API項目的 Startup類 中實現了 註冊擴展功能
