關於基礎組件的開發與基礎架構的搭建


基礎組件是相對於業務功能來說的,因為業務線的事務一般比較繁雜,在沒有基礎組件的情況下,遇到相似功能的復用大多是直接copy代碼然后再粘貼修改。這樣的話,類似功能存在多份代碼,如果要修改一個BUG,就需要找到所有的相關代碼然后再修改,費時費力,效率也不高。而且當需求功能復雜時,代碼量也會隨之增加,維護成本也相應增加,調試修改都變得很麻煩。所以我們需要在業務層下面抽象出一個基礎組件層,該層介於基礎庫與業務代碼之間。

  我們來看看這種輪播功能:

               

 

  這是很常見的內容輪播組件,在編碼前我們需要找到這種組件相對變與不變的需求點,


  不變的地方:
    都具有一系列內容
    具有自動播放功能
    可以人工進行切換內容


  會改變的地方:
    圖片大小不一樣
    可能某些產品的需求會有說明文字,某些沒有
    按鈕的樣子和位置不一樣,某些需求沒有交互按鈕
    不同的產品中,會有不同的動畫切換效果

  由此可以看出,改變的大多是UI和交互層面的,所以我們可以把本質的不變的東西直接抽象出來,再把UI層面的剃除出去就可以得到以下的設計思路:

    1.列表管理功能,管理添加的內容。
    2.切換功能,用以切換列表
    3.播放功能,用來讓內容自動輪播
    4.UI渲染功能,通過配置不同的模板來得到不同的UI呈現

  以上是按單一職責原則把各功能進行了拆分,抽離了基本邏輯和UI層,用圖來描述大概就是這樣:

    

  其中,List列表功能管理內容,因為這種切換內容的數據結構是線形的,所以用列表描述就夠了,然后其包含了“添加”、“刪除”、“插入”和“清除”功能;
  Switch切換功能是對列表數據進行管理,可以獲取到需要的內容,包含“下一條”,“前一條”,“跳轉到某一條”功能;
  Player播放功能可以實現自動播放,包括“播放”和“停止”功能;
  然后這里抽象出了一個View接口,並且有二個View類實現了該接口(ViewClass1和ViewClass2),於是接口的render方法就得到了不同的實現,用以呈現不同的UI風格。

  這樣做有什么好處呢,
  首先,我們把各功能拆分出去后,各功能間就得到了解藕,代碼間的影響就小了,這樣對於代碼維護也方便了很多。比如發現自動播放功能有個BUG,可以直接找到Player這個類進行排查修改就行,不用再在一大坨代碼里去找半天;
  其次,拆分后的代碼復用率得到了提高,遇到相似功能的需求時就不用直接COPY代碼修改,而是獲取現有的功能來使用或封裝;
  最后,以后有類似需求的擴展,只需要再開發實現View接口的類,配上不同的模板既可,而且不會影響到基礎功能。

  最后再簡單總結一下,做需求開發的時候,先考慮下該功能層面的變與不變的點,然后再跟據單一職責原則進行功能拆分,分離開各獨立功能以達到解藕的目的。




前端架構搭建心得

 

在這個公司待了半年多了,對公司的心情就不暴露了,不過有幸的是在最后的日子里面接手了一個讓我盡全力去做的項目(CQM系統)。ps:原作者可能寫錯了,CRM(Customer Relationship Management)--客戶關系管理
從第一家公司上班到現在,我也在網站這塊揮霍了1年半的青春了,從后端到前端,從陌生到熟悉,漸漸的對網站的知識開始穩定的深入學習了。 
我一直想自己做一個像樣的東西,可是每次都沒法下定決心,1是自己能力不夠,2是時間上自己想偷懶,所以這次的CQM項目也算是對自己一個小小的檢驗吧。 
ok,開始說正題,在公司我不屬於項目部,由於其它原因我有機會負責這個項目的前端框架這塊。 
和自己想的一樣,這是一個小小的OA項目,因為前端這塊基本上我完全負責,所以里面的東西基本都是我自己的想法。 
PS:由於有些內部資料,我不方便透露,見諒.



上面的圖片是目錄結構,接觸過微軟MVC的同學應該看出來了,沒錯,雖然我做前端,但是我學過C#,熟悉的就是微軟的MVC,現在我用的是MVC4,當然,我用到的IDE認識微軟MVC的同學也知道了吧。
首先,雖然做前端,但是我自己也需要一個簡單的服務器來處理一些數據,MVC(后面的MVC皆為微軟的MVC)是我一個不錯的選擇,因為只會這個嘛。。。


拋開其它的文件夾,主要看展開的兩個. 

statics和views文件夾,第一個[statics]里面裝的是一些靜態文件,當然ashx是放錯位置了,這東西修改后需要編譯,不過這東西用的不多。第二個[views]里面是頁面文件。


用於我這邊沒有和項目組一起,在單獨做,所以完全是前后端分離,只用了一些數據測試的后台編程。 
我做前端的時候大體思路是:模版布局、控件組合生成、目錄結構布局。 
怎么理解這句話呢,我下面用一個圖來說明. 
           
這兩張圖是statics文件夾的說明圖,因為我內部有內嵌框架,所以就有了father和son這兩個文件,因為第二層內部有可能還有一個內嵌框架,end這個文件也就出來了。 
下面這張圖是頁面布局的一個草圖



從上圖中可以看到,整個前端頁面有3層,當然,也可以做成1層,不過因為ifrmae的框架變化很大,所以我就用3層包裹了。PS:左側導航屬於第二層. 
圖片3中json文件夾是存儲網站需要的json數據格式的,ashx文件夾中用於測試服務器數據,plugin文件夾里面放的是js的各種框架。 
zoeDylan是前端的數據處理層,無需任何其它js框架,dgg是元素交互和元素處理層,用了jq框架。 
綜上所述,前端靜態文件和頁面數據塊差不多就這樣了,接下來是views文件夾.



其它文件夾就不說了,主要是shared共享文件夾. 
同上,son是第二層的視圖公用文件,end是第三層公用的視圖文件,header是頭部內容,frame是所有層都需要的,主要是一些文件引用。 


到這里頁面的文件就ok了,接下來是邏輯思路說明. 
做這個項目的時候才開始很有激情,但是1個月過去了就感覺到了吃力,因為我發現自己的能力不夠啊,但是代碼都寫了幾萬行了,總要有些用嘛。 
整個前端的邏輯是:后台拼合視圖模版,js處理數據和顯示。



頁面從請求到展示的邏輯就是這樣了,紅線是必須加載,綠線是可能加載,最后是frmae頁面中呈現,{請求一個頁面地址-模版套用-輸出}會mvc的同學應該知道mvc頁面是怎么處理的,這里我就不詳細說了。


ok,頁面加載完成了,那數據呢?
我這里的數據是json與ajax的交互完成的,頁面處理的過程中會在模版指定的div或者直接運行js上添加一個json的數據請求地址,地址會返回一個json格式的數據,然后js就開始處理,生成最后呈現在頁面上的內容。


這個是dgg.js文件,用於處理數據,認真的同學會發現這個文件會創建dgg和_father兩個全局函數。沒錯所有頁面都會有這兩個全局函數,dgg是包含了所有公用的數據和元素處理函數,_father是包含了最頂層框架的函數,為什么要這樣做呢?
1:dgg中繼承zoeDylan.js是為了統一函數,應該公司需要嘛,我就這樣做了,
2:_father是為了調用頂級頁面的一些事件,比如說全屏彈窗、狀態顯示、消息推送等。 
這里主要說一說dgg.element這個函數,因為頁面的數據完成基本上都是這個函數在處理。 
dgg.element是一個創建頁面組件的處理程序,你傳入一個json格式數據,然后會根據你指定的組件名稱創建一個組件,然后返回一個jq函數的組件。 

下面是dgg.element函數的一些截圖
             
dgg.element開放的方法只有兩個:dgg.element.create和dgg.element.template
前者是創建組件,后者是定義組件模版的. 
dgg.element的處理邏輯是:調用開發方法create-內部處理:jsonSet判斷組件,提取模版tempLate中的模版樣式---調用eleTemplate中對應的組件方法,用於處理組件事件---調用setAttr方法,用於處理公共元素屬性---返回jq函數的組件 
這里tempLate可以自定義在json的數據中,也可以用dgg.element.template配置模版和模版方法eleTemplate。下面舉一個例子:

例子:生成一個組件



我要生成上面的組件,我傳入的json格式就是


json中eName就是模版名稱,獲取json后調用dgg.element.create(json),開始處理步驟

1:先是jsonSet處理數據,主要判斷是否是多個組件

2:創建組件

3:組件事件編寫,里面就是組件一系列的處理,包括組件的事件等

4:公用的組件屬性處理


到這里這次筆記就結束了,由於樓主經驗不足導致搭建過程中出現了N多問題,現在都還有一堆問題沒解決,由於過年了放松下,年后還有加班加點做,這次的項目中自己學到的東西也不少,很容易就發現自己的不足和經驗的欠缺,這次寫這個筆記是對自己的第一次寫前端架構的一個總結和記錄,項目不怎么樣,新人可以看看學點邏輯的東西,大神求指點,




注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com