|
一,、Angular,，它兩個版本都是強主張的，如果你用它,，必須接受以下東西： - 必須使用它的模塊機制 - 必須使用它的依賴注入 - 必須使用它的特殊形式定義組件（這一點每個視圖框架都有,，難以避免） 所以Angular是帶有比較強的排它性的,，如果你的應用不是從頭開始，而是要不斷考慮是否跟其他東西集成,，這些主張會帶來一些困擾,。 二、React,，它也有一定程度的主張,，它的主張主要是函數(shù)式編程的理念，比如說,，你需要知道什么是副作用,，什么是純函數(shù)，如何隔離副作用,。它的侵入性看似沒有Angular那么強,，主要因為它是軟性侵入。 你當然可以只用React的視圖層,，但幾乎沒有人這么用,，為什么呢，因為你用了它,，就會覺得其他東西都很別扭,，于是你要引入Flux，Redux,，Mobx之中的一個,，于是你除了Redux，還要看saga,，于是你要糾結(jié)業(yè)務開發(fā)過程中每個東西有沒有副作用,，純不純，甚至你連這個都可能不能忍： const getData = () => { // 如果不存在,，就在緩存中創(chuàng)建一個并返回 // 如果存在,，就從緩存中拿 } 因為你要糾結(jié)它有外部依賴，同樣是不加參數(shù)調(diào)用,，連續(xù)兩次的結(jié)果是不一樣的,，于是不純。 為什么我一直不認同在中后臺項目中使用React,，原因就在這里,，我反對的是整個業(yè)務應用的函數(shù)式傾向，很多人都是看到有很多好用的React組件,，就會傾向于把它引入,，然后，你知道怎么把自己的業(yè)務映射到函數(shù)式的那套理念上嗎,？ 函數(shù)式編程,，無副作用,，寫出來的代碼沒有bug，這是真理沒錯,，但是有兩個問題需要考慮： 1. JS本身,，有太多特性與純函數(shù)式的主張不適配 2. 業(yè)務系統(tǒng)里面的實體關(guān)系，如何組織業(yè)務邏輯,，幾十年來積累了無數(shù)的基于設計模式的場景經(jīng)驗,，有太多的東西可以模仿，但是,，沒有人給你總結(jié)那么多如何把你的厚重業(yè)務映射到函數(shù)式理念的經(jīng)驗,，這個地方很考驗綜合水平的，真的每個人都有能力去做這種映射嗎,？ 函數(shù)式編程無bug的根本就在于要把業(yè)務邏輯完全都依照這套理念搞好,，你看看自己公司做中后臺的員工，他們熟悉的是什么,？是基于傳統(tǒng)OO設計模式的這套東西,，他們以為拿著你們給的組件庫就得到了一切,，但是可能還要被灌輸函數(shù)式編程的一整套東西,，而且又沒人告訴他們在業(yè)務場景下，如何規(guī)劃業(yè)務模型,、組織代碼,，還要求快速開發(fā)，怎么能快起來,？ 所以我真是心疼這些人,，他們要的只是組件庫，卻不得不把業(yè)務邏輯的思考方式也作轉(zhuǎn)換,，這個事情沒有一兩年時間洗腦,，根本洗不到能開發(fā)業(yè)務的程度。 沒有好組件庫的時候,，大家痛點在視圖層,，有了基于React的組件化，把原先沒那么痛的業(yè)務邏輯部分搞得也痛起來了,，原先大家按照設計模式教的東西,，照貓畫虎還能繼續(xù)開發(fā)了，學了一套新理念之后,，都不知道怎么寫代碼了,，怎么寫都懷疑自己不對，可怕,。 我寧可支持Angular也不支持React的原因也就在此,，Angular至少在業(yè)務邏輯這塊沒有軟主張,，能夠跟OO設計模式那套東西配合得很好。 框架是不能解決業(yè)務問題的,，只能作為工具,，放在合適的人手里，合適的場景下,。 三,、Vue，可能有些方面是不如React,，不如Angular,，但它是漸進的，沒有強主張,，你可以在原有大系統(tǒng)的上面,，把一兩個組件改用它實現(xiàn)，當jQuery用,；也可以整個用它全家桶開發(fā),，當Angular用；還可以用它的視圖,，搭配你自己設計的整個下層用,。你可以在底層數(shù)據(jù)邏輯的地方用OO和設計模式的那套理念，也可以函數(shù)式,，都可以,，它只是個輕量視圖而已，只做了自己該做的事,，沒有做不該做的事,，僅此而已。 漸進式的含義,，我的理解是：沒有多做職責之外的事,。 |
|
|
來自： loudf > 《移動Web開發(fā)》
