2014年7月5日 星期六

Review 一下 2014年 web 軟體開法者應該要設略的技術/工具。

Review 一下 2014年 web 軟體開法者應該要設略的技術/工具。



版面工具
A. Boostrap

Javascript 工具
A. jQuery
B. TypeScript
C. Angularjs

其他web的 UI 工具
A. jqGrid
B. highcharts
C. 其他著名的重型 Javascipt UI工具

以上被點名出來的原因是。
許多服務最終都是以Web的方式呈現。( android , ios 另外討論)
因此在UI呈現與撰寫的工具上,應該轉向前端的工具。
這句話是對應如 WebFrom  , dotNet MVC 的 Razor 以及 java 陣營的 jsp , swing 的 UI 工具。

java部份我累積的經驗很少,僅就dotNet點出, 由webform打造出的網頁應用相對來說,因為是以windowform 的基礎下去時做的。反而要去注意每個元件的生命週期與榜定的問題。一個頁面裡面的業務項目多了,資料的bind控管就變得很複雜,因為webform每次都要重刷, update pennal 雖然可以解決一些問題,但也會製造一些坑出來。
與其使用這個模擬前端的UI工具。倒不如直接使用 前端的框架來完成這些工作。

在前端 就是兩個主要角色  dom 與 javascript .以及使用javascript上的 ajax工具
原本 webform 的 生命週期, viewStat 都不需要去裡他了。
我們只要針對要CRUD的對象,將新的值取回來,在放到原來的dom位置上就好。

所以未來,C#與java等語言,就可以只著重在 business model , DataAccess 的任務上就好,
而介面將會 交給 Web的前端工具來處理。

這樣的分工,在Client 端需要在 Android , iOS 等其他Native的介面上時,我們也只要在另外實做該平台的Client UI 就能提供不同 OS的使用者使用了。

那前列的幾個工具就是在,網站應用上的基本功夫了。

---------------------------
那後端該怎麼選擇呢?
以目前的趨勢,所有產品都有很大的機會面臨,跨網域的服務,以其手機時代的跨Clinet UI 的需求。專案架構上,最好是抽出一個服務層 如  web service , 或是 WebAPI 作為業務資料的提供者。 由不同的前端透過相同的API來取用資料。

而微軟,似乎也是以 asp.NET MVC 作為此類架構的基底 。
文章前面提到了前端的工具,因此 asp.Net MVC 的分工,可能就要把 View 的任務交給前端,
*.cshtml   razor 的任務會很輕量 定位dom元素, include  js  css 等檔案資源。

但是 controller , model 的角色還是留給 C# ,  asp.Net MVC 自己扮演。
  asp.NET MVC 5 ,也即將發佈到 6了。
 對於model的機制與工具持續的強化,協助資料驗證的valid annotation,透過EF 實現了orm的機制,降低初期要實做資料存取功能的時間花費。

在 controller 上面 , 在一次的強化了  Fillter 的機制,讓 controller 擁有 AOP 的好處。
如此針對個別功能(單一 method) 作特定角色的操作限制, 或是寫log ,以及例外處理等。
透過適當的 AOP 設計,達到不干擾 Controller 程式碼可讀性的目的。又能確保該有的機制都能完整的進行任務。

這是在後端開發上的基本功。

以上的前端與後端 其實都是在打 工匠的底子 , 是技術活, 簡單的講是賣勞力的,不過因為有了一些技術工具的輔助,  花費相同的勞力,卻有辦法產出更多,或是能更快得達成計畫中的目的。  這也是本文要點出的價值之一。

---------------------------
技術與體能的部份確定了。

還剩下一個  心智的部份。 因應客戶的需求,設計/架構出滿足需求的產品/服務。
從需求的挖掘、整理分析、擬定系統架構、轉換需求變為系統設計、實做設計的功能。
除了最後的實做是與  c# 與 前端語言 的關聯性很大。 其他階段的任務都是不同的功夫,而且是跟用什麼語言沒什麼關係的部份。

又是另一個學習與應用的領域了。

沒有留言:

張貼留言

歡迎回饋