理論來自於實踐，並指導於實踐 - 佚名我相信在mvc等理論形成之前，就已經有人在付諸mvc的實踐。只是後來有人總結下來，並指導人們做軟體開發。這種設計典範並不是只有後台的**才有，前端也可以有很好的框架，像react和vue。
為什麼這麼強調實踐。因為在我學習mvc理論的時候，我是蒙蔽的。雖然看了很多優秀的文件，比如，阮大神的mvc，mvp 和 mvvm 的圖示
看了之後挺有感覺，興沖沖寫**的時候，又感覺不知所措。不知從何下手，不知如何劃分。
最近在用react，又幫別人寫了乙個jquery**，現在將這種套路試著總結一下。
從後台獲取資料，渲染乙個簡單的列表，實現列表的增刪改查
類似於這種
這是之前寫**的套路：
頁面初始渲染時，從後台獲取資料（乙個陣列）
將資料使用 字串拼接 或者 前端模板 將資料渲染到頁面中
給渲染的列表繫結增刪改查的事件
拿乙個刪除舉例，點選刪除按鈕，獲取當前行資料的id值，傳送ajax請求，根據id在後台資料庫中刪除，返回成功碼，前端將當前行使用dom方法刪除
其他的事件也是類似，在ajax的成功**中進行dom的操作，畢竟jquery是dom操作神器，操作起來都感覺6的飛起
在元件中定義state.arr將即將要渲染的資料儲存在其中
寫html模板
請求資料，setstate資料值，資料改變，頁面自動重新整理
接著拿刪除舉例，點選刪除按鈕，獲取當前行資料的id值，傳送ajax請求，在成功的**中，使用
let a = this.state.arr.filter(item => item.id !== id);
this.setstate()
5. 其他事件也是類似，從始至終都沒有再操作過dom，只是各種使用setstate方法，來維護要展示的資料
這種方法肯定就是著名的mvc模式了。和第一種比起來，就發現這種好處是什麼。我們只專心的運算元據，維護狀態，從沒有去操作過dom。
讓我們精力更集中。
適時放一張圖來感受一下。
看著上圖來念一遍：資料改變 -> 檢視重新整理 -> 事件修改資料（controller）-> 資料改變再次渲染檢視。
抄一段阮一峰大神部落格的原文
view 傳送指令到 controllertips:因為jquery是操作dom神器。使用react和vue都不建議直接操作dom，所以用框架的話還是早是日脫離jquerycontroller 完成業務邏輯後，要求 model 改變狀態
model 將新的資料傳送到 view，使用者得到反饋
如果感覺不強烈，可以畫一張示意圖來看一下，第一種方法的流程是什麼樣的。
獲取資料後 -> 渲染了一次檢視 -> 監聽事件完成後台互動 -> 又雙叕粗暴的改變了檢視
我們要維護乙個狀態陣列，陣列改變後，就去重新整理檢視，監聽事件，改變狀態
準備工作：
因為jquery不會自動重新整理檢視，還是需要寫乙個render方法來渲染檢視，這個方法在初次渲染資料和修改資料後改變都要執行的。
var arr = ; // 要維護的資料
function render(arr)
function bindevent()
上面實現了簡陋的mvc。會發現，不管arr狀態有個風吹草動，整個列表都會重新呼叫渲染方法。react和vue內建了各種diff演算法，避免了這個尷尬。
未完待續。。。
實踐出真知之Oracle篇
儲存過程跑批小迴圈 可根據自己的情況適度修改 declare o ret val number start days varchar2 8 end days varchar2 8 begin start days 20200101 重跑開始日期 日期不固定可根據自己需要的日期進行修改 end day...
實踐出真知（神經網路篇）
roofline model 提出了使用 operational intensity 計算強度 進行定量分析的方法，並給出了模型在計算平台上所能達到理論計算效能上限公式。roof line model 模型在乙個計算平台的限制下，到底能達到多快的浮點計算速度。更具體的來說，roof line mod...
前端樣式實踐出真知系列（二）
1 overflow 屬性規定當內容溢位元素框時發生的事情。當屬性值為hidden時，元素內容會被修剪，並且其餘內容是不可見的。哪些元素會被修剪 超出元素邊框的部分 不管它是內容本身過多導致的 還是通過定位 相對或絕對 導致的 都將隱藏。2 maring外邊距祥解 乙個元素的margin影響了父元素...