咱們活在當前,一個史無前例的時代,一個面向彼此的環境!前端
最近一段時間一直在學習各類框架知識,前端的後端的,如今來總結一下我的的感受和心得!程序員
校務管理系統:數據庫
若是咱們如今開始接手一下:"校務管理系統",那麼咱們須要作什麼呢?後端
1.考慮問題 :安全
①:咱們須要管理那些(校務人員、學生、教學環境、圖書館、教務系統、。。。)服務器
②:也就是說咱們一個校務管理系統可能要包括多個子系統,框架
2.OK,如今想通以後咱們繼續開發,首先選擇了咱們熟悉的學生管理做爲第一個系統,開始系統原型界面、數據庫模型的設計分佈式
開發中。。。微服務
開發一段時間以後,咱們發現咱們的進展很慢,怎麼辦呢?開個碰頭會吧,你們一塊兒討論討論:佈局
唧唧。。咋咋。。。
會議室內吵成一鍋粥,原型應該這麼設計。。。,你這麼設計誰看得懂啊 ,要我說,界面應該美觀,大氣,你大氣給誰看啊,那些教授都40多歲了,漂亮有什麼用?
問題出來了:
①:因爲咱們沒有良好的溝通交流已經分工,如今你們對於原型界面、系統規範、以及業務調用都處於混亂狀態
②:因爲咱們同一個系統使用的人羣不同,可能界面需求須要變動
ok,瞭解以後,身爲組長的我決定,小芳,你是美術出身,你來設計前端,小王,你是計算機出身你來作後臺,其次數據庫每個表 字段都須要寫註釋,後臺代碼也同樣
一個頁面對用一個後臺,
開發中。。。
開發一段時間以後,出現以下狀況,王哥,我這個頁面怎麼出問題了?出不來了報錯了,哦!是什麼頁面,就是排寢那個地方,哦,我在改動代碼,你等會啊,那行吧,你快點兒,我剛剛改動了樣式,須要看看效果,而後小芳去倒了杯奶茶,等着後臺修改完成以後才能繼續運行界面(這就是咱們傳統的WebForm窗體開發),後臺和前端關聯太緊密了
怎麼辦呢?集思廣益吧,再開個碰頭會。。。
如今咱們開發的進度又滿了下來你們說說都有什麼問題:
①:東西太多太雜了,誰知道啊image文件夾裏面竟然放了JS文件,個人天啊
②:還有先後臺太緊密了,人家想改東西都改不了
。。。
OK,瞭解問題以後咱們去解決這個問題,首先是資源管理的問題,咱們要求將全部的資源文件放入Content文件夾中,引用的第三方文件存放入指定的 ThirdParty文件夾中按名稱存放,其次是關於先後臺緊密的問題,咱們採用將後臺文件當前封裝在類庫中,而後在編譯階段指定編譯的路徑,這樣咱們後臺改動若是不從新編譯生成BLL的話,前端界面也就不會收到影響,由於在以前的BLL已經存在對應的後臺代碼
好的,如今咱們來整理一下咱們如今的系統,比較簡潔的主程序入口,由於咱們將資源文件(Content)、第三方插件(ThirdParty)、前端頁面(WebUI)都按照功能存放在對應的文件夾中,其次後臺代碼封裝在一個類庫中,一樣按照不一樣的功能模塊封裝在了各自的文件夾中,看起來很整齊哦
好吧,那咱們再開個朋友會鼓勵鼓勵你們 :
① : 王哥,你怎麼了,耷拉着個腦殼,哎別提了,新來的小趙對咱們業務不熟悉,非的我一把手的交,作東西找目錄啊什麼的慢死了、
② : 小芳,那你呢 ?哎 別提了,最近數據量比較大,調整樣式啊時候須要等半天數據纔出來
。。。
ok,繼續來總結一下問題,新來的員工對於系統上手速度慢,顯得系統過於冗餘,其次,數據的增多致使數據訪問變慢
咱們這裏提出一些觀點和思路:
①:系統冗餘,因爲咱們對數據庫的操做頻繁致使在後臺邏輯業務層和數據訪問層中的代碼增長,要寫一個業務功能,須要觀察數據庫,找到對應的關聯字段,在模型類中添加一個新類,在數據訪問層(DLL)--邏輯業務層(BLL)建立各類的新類,在UI層建立對應的頁面,而後依次編寫代碼完善功能。
②:數據庫須要優化 分擔訪問壓力
③:系統沒有統一的目錄,介紹或者說是索引,
解決:咱們在開發的過程當中總結出一些規律(針對於業務而言):
①:前端:角色 、權限; 前端的操做無非是增刪查改、在這個過程當中須要兩個東西一個是當前操做的用戶、操做的信息
②:後臺 : 對於數據庫的增刪查改訪問大體相同 好比查詢單條數據 查詢列表 根據參數查詢 添加 修改數據
針對此咱們決定,再開一個小組,準備開發一個新的框架,以適應如今的業務:
①:前端:建立一個新類basePgae(baseController(控制器)) 添加一些默認的操做 建立一個屬性id 獲取請求中的Requert的Id,添加驗證StringNotNull(要驗證的字段,字段的名稱,字段的長度)、IntNotMax(要驗證的字段,字段的名稱,該值的最大值);等等,比較重用的方法,儘量的封裝在這個類中,在之後的開發過程當中前端頁面繼承此類便可,在訪問修飾符爲Private私有時,程序編譯後生成BLL文件屏蔽內部信息,比較安全
②:後臺:建立一個基類BaseDLL爲泛型類,添加Add、Update、Delete、Get 等通用方法,使用泛型<T>獲取要操做的類型(對應的模型/數據庫對應的表),用反射建立該類的對象實例,根據這個類的信息去操做對應的數據庫表,在這個過程當中能夠將參數做爲一個鍵值對的集合,進行驗證後 將參數拼接到Sql語句中,一樣咱們能夠爲這個操做提供一些重載,必要的分頁,獲取受影響行數,獲取記錄總數等等的一些方法,
③數據庫:在BaseDLL中開放出數據庫鏈接字符串這個位置,讓其能夠接受參數傳入,達到的效果應該時,個人一個業務程序集也就是類庫,脫離於前端存在,不須要依賴前端的配置文件傳入數據庫鏈接,
So,如今咱們再來整理一下咱們的系統,系統更新框架後,本來的系統不須要改動(有需求的話能夠改動),在繼續開發的過程當中,咱們前端人員只須要負責好前端的樣式(控件、佈局)等等一些東西,可是全部的操做不會基於後臺數據,在和後臺交互的過程當中會使用開發人員給定的一個訪問地址也就是Ajax中的Url,在通常的調用中(通常處理程序、WebServer、MVC)調用中每每咱們須要這樣書寫URL //網址/路徑/訪問的訪問(Action/標記),所以咱們也能夠說是面向接口,工做中人員經常提到接口接口,主要是指一個訪問的地址,其次在後臺,添加新功能時,須要建立對應的實體類,隨後建立Bll層繼承BaseDLL就能夠得到通用的方法GetList<模型類>()查詢全部、GetGetList<模型類>(參數鍵值對集合)/、Add(要添加的對象)等等方法,而在控制器,或者和前端交互的類庫中咱們須要建立一個新類繼承basePgae(baseController(控制器)),建立對應前端控件的屬性等一些操做(詳細請看我以前的隨筆,關於框架設計的部分),準備完成後,好比我但願在添加的時候獲取一個對象的信息,咱們能夠直接Bll.Get(id);由於基類中咱們定義了Id因此在這裏可使用,避免咱們再次從請求Requer中獲取,"只有規範的基礎纔有可能去搭建一個框架,框架也要求咱們在使用時去遵照一些規約"
Ok,繼續開發,如今咱們有了新搭建的框架,開發的效率固然也提升了很多,但是生活老是不會讓咱們如意,這不前不久數據庫出現了奔潰,訪問太慢了,所以英明的我決定,"分佈式"部署數據庫和程序,不過首先咱們要來回顧一下咱們的系統,首先咱們接手了一個校務管理系統,通過討論後咱們決定先行開發學生管理模塊,在這過程當中咱們出現了一些問題,可是都被咱們克服了,可是隨着子系統慢慢的完善,集成到總系統中出現了問題,所以咱們決定用分開部署的方式緩解其中的壓力,
Lef's Go:
首先讓校務管理系統系統部署在個人電腦,固然咱們會購買域名了,可是當你們訪問時,實際上是我這臺電腦(服務器)爲你們服務了,隨後當你們訪問子系統學生管理時,咱們的程序會去運行我本地的程序集,當須要更新數據的時候會訪問到咱們程序員小王的電腦,爲何呢?由於咱們在程序集中配置了數據訪問層的配置文件,將子系統學生管理數據庫鏈接配置成了小王的數據庫,這樣請求發送到小王數據庫完成後,再返回給我由我來作處理,依次推之,咱們美美噠的小芳當之無愧的獲取的圖書館系統的部署,這樣一來,咱們就將數據庫的壓力緩解到了其餘的電腦,運行其餘電腦的爲咱們計算工做!! 我是否是很英明神武啊 (●ˇ∀ˇ●)
哎,我以爲本身太棒了,這不前兩天省局的人找過來了,說想調用咱們的接口(程序),完成一個圖標彙總的功能,要獎勵國家獎學金啊,這感情好啊是吧!可是我一想這不行啊,雖然我將數據庫的壓力緩解了但是程序的運算但是都放在個人電腦的呀,要是爲省局這件事,個人系統可能要炸啊:
問題出來了,雖然咱們的程序將數據庫部署分開了,可是實際上關於項目的運算都是集中我這一臺電腦上的!怎麼辦呢?有了我使用服務來作這一件事(微服務、服務開發),
爲何要用服務呢(WerServer、Wcf、通常處理程序),由於咱們在訪問服務時,數據不須要咱們來處理,想一想看,我在百度查詢<黃家駒>,並無在我電腦本地運行程序,而後去對應程序集查詢而後對應數據庫吧,而這一過程顯然是交給了百度,誰讓人家有錢買得起好的電腦呢(服務器),也就是說我不在使用引用程序集的方式去部署個人校務管理系統系統,而是轉用服務的訪問,
如今咱們程序運行的方式應該是這樣的:登錄校務管理系統,一些頁面的瀏覽由我本機提供,但訪問子系統圖書館管理時就將這一請求發送到了咱們美女程序員小芳的電腦,小芳電腦的服務器(IIS、Tomacte)接受到請求後開始解析,指定對應的程序集,開始運行判斷 訪問數據庫,返回數據 最後在接處返回