接觸angular技術也有一年多了，來newegg也剛好一年了，在這一年裡，學到了不少關於前端技術的精髓，但是讓我最興奮的，莫過於發現了模型系統，之所以認為它神奇，是因為一切複雜問題其實都可以通過模型系統來很好的進行抽象建模，使得你的工作可是事半功倍。
1)、angularjs通過資料雙向繫結使得view層和controller進行很方便的資料操作，並帶來很好的使用者體驗。
2)、angularjs使用指令directive、服務service等進行更好的模組化管理，使得**元件化管理，做到了更好的復用。
3)、angularjs裡內建的很多服務能夠簡化開發成本，如http服務等。
但是，超爽的開發體驗必然會有一些難以啟齒的痛點，我記得我當年一開始做乙個郵件模板管理系統時，其中有乙個頁面是關於新建郵件模板的業務邏輯，這個頁面是相當複雜的，其中乙個頁面就包括模板新建、模板測試、模板copy、以及預覽模板等功能，前端部分我只做了一小部分，可是這部分在之前的controller中新加業務，導致controller中的**達到乙個**式的增長，這個js居然高達1000多行，對後續維護造成非常大的不便，這些痛點在我心裡非常之痛。
之後我終於明白，原來我在整超神的controller (gode like!)
1)、前台html**和後端view的js**進行繫結。
2)、controller中做資料初始化。
3)、controller和service層做資料互動。
4)、controller層對頁面控制展示等做控制。
5)、controller中包含頁面表單的相關驗證以及對service層提交資料。
6)、controller層對業務邏輯的封裝。
以上幾點，相信大家在開發angular的時候，都深有體會，因為angular你在網上找的demo他就是快，直接在view層繫結乙個model的變數，然後在controller中即可進行雙向繫結了，那麼隨著需求不斷迭代，我想幾個月後，你自己都不願意看自己的**了，god like自然也就來了。
在這裡，自然會想到我們的設計原則：單一職責原則！切記，模組的職責要單一，乙個類只幹一件事，會讓**更清晰！
前端系統的本質：業務模組 + 頁面 + 元件 + 功能點。
元件又分為：
1)、公共ui元件，例如外觀上長什麼樣子，行為上他能幹什麼。
2)、業務元件，外觀是業務內容，行為是業務是什麼，在什麼特定場景下能幹什麼。
對於ui元件，我們可能會想到有表單驗證、使用者控制項、以及一些第三方元件等，這些可能有架構師或者你自己來封裝，這裡我要重點強調下業務元件，如何將如何將業務模組化、服務化、一旦做到這兩點，那以後的開發可謂勢如破竹。
我們來分析下如下這個例子：
上面這個頁面是我們再熟悉的不過的登入頁面，復用度不用多說，經常在不同的系統中會見到這個模組，然而我們每次開發這個頁面的時候都要去手寫html然後建立後台controller**嗎？顯然這樣做你就out了，我們何不將他封裝成乙個directive，這樣每次只需要引入這個directive之後即可，而對應的login 向伺服器發請求等只需要做成配置，將使用者名稱和密碼傳送到伺服器端就可以了，這樣豈不是以後再做另乙個系統的時候直接拿directive的js引過來就可以了，是不是很屌呢？
說道這裡我想說我們的另乙個原則
知道最少原則，即，依賴自製，模組間要做到高內聚，模組外做到低耦合，只需向模組外暴露對應的資料介面就可以了，避免看複雜的邏輯導致開發效率變低。
有了以上的認識，你是否發現，在我們的日常開發中，如果能多引入模組化，服務化的開發思想，是否會讓你覺得人生豁然開朗了呢？那麼模組化更高境界是什麼？
答案就是：系統建模！
我相信所有的同學都知道，下面這兩點：
但是我要說，這一切其實都是在建模！
那麼系統建模包括哪些呢？
那麼模型系統中，哪些可以進行模型化呢？
1)、資料模型化，通過json schema將前端資料和後端資料進行通訊，實現資料建模。
2)、業務模型化，將業務邏輯封裝成模組，之後只需使用依賴注入原則引入即可使用。
3)、表單模型化，將表單做成公共元件，方便呼叫。
4)、列表模型化，列表進行公共元件封裝。
5)、橋梁指令模型化，鏈結業務模型，資料模型和檢視模型，模組間的互動使用標準介面，實現元件的模型化管理。
那麼更具體的前端系統建模是怎麼看呢，下面為大家隆重介紹具體的模型系統！
上述圖是我在一位高人的指點下分析出來的前端模型系統構架猜想，這其中的好處就在於：
1)、實現了前端使用者檢視層、業務邏輯層、資料層、後端服務層的解耦，使得系統耦合性更低，更具有彈性。
2)、前端頁面將常用元件進行封裝，如列表、表單、下拉列表、等的封裝，以後直接用即可。
3)、使用橋梁指令，將一些控制項的行為進行指令化得管理，例如乙個editor中的基本驗證，使用指令來完成，以後類似editor直接呼叫指令即可，省去重寫驗證的邏輯。
4)、業務邏輯服務化管理，不在針對某個單一的業務進行程式設計，而是將業務歸類，做成配置項等，以後只需呼叫公共業務元件即可。
5)、前後端使用json schema進行資料通訊，後端使用什麼語言不再重要，只需做成service api 服務即可。
6)、後端模型黑盒化管理，前端程式設計師不需要知道後端**，只需通過request向後端發請求拿到response做出處理即可。
其實這一切的一切都離不開兩個字：抽象！
開發程式本是照本宣科，bsd說什麼我們做什麼，但是優秀的程式設計師總會看到眾生萬物背後的道，從而做出松耦合、更具彈性的設計。
這一年裡，我沒請過假，沒遲過到、沒早過退、bug數也急劇降低，人生那麼短暫，最痛苦的事莫過於不進步、不學習、不努力、不思考、
賀煒的一句話驚醒了我，人的一輩子除去睡覺也就那麼一萬多天，區別就在於你真正是活了一萬多天，還是一件事重複了一萬多次，人生如白駒過隙，以後的日子要倍加珍惜，相信下一年裡一定更有收穫！
1 系統建模
1.需求清單 好友之間互相發訊息 qq群內與群友交流 使用者和訊息管理 2.需求總結，即目標 qq的使用者 使用者 qq的功能 一對一聊天和多對多群聊兩種情況 我們現在對以上需求和功能進行總結輸出。首先，qq在沒有註冊的情況下是不能使用的，所以我們的使用者沒有遊客的概念。那我們的使用者一共可以分為兩...
課程註冊系統建模
為某大學建立乙個課程註冊系統模型。從分析開始，進行軟體的基本配置 語言選擇 用例檢視 序列圖 類圖 元件和部署檢視建立等，還要進行關係型別和屬性的配置。1 啟動rational rose 如果使用rose的企業版，則在creat new model對話方塊中使用選new標籤中的vb6standard...
軟體系統建模 UML
目錄 一，建模視角 二，建模方法 三，uml 1，事物 2，關係 3，圖用不同的模型來從不同的視角表示系統 1.外部視角，會對系統的上下文或環境進行建模 2.互動視角，會對系統及其環境或者系統的構件之間的互動進行建模 3.結構化視角，會對系統的組織或者系統所處理的資料的結構進行建模 4.行為視角，會...