從Silverlight開發架構看到的一些感慨

最近在撰寫Silverlight的文稿(書稿和雜誌稿)、範例、和一些課程教材的時候,看到Web開發技術的發展回頭對比台灣的開發環境實在有一些感慨。

先講第一個,話說從頭,有一陣子我介紹了ASP.NET上的MVC,MVC這個架構是個好的Pattern,可以幫助開發人員達成建構出有架構、便於更新維護、便於抽換的應用程式,問題是這是(只是)一個規範、一個樣式,所謂的規範就表示,你應該遵循藉以得到一些好處,但是有趣的是,規範這個東西在台灣不見得一定會被遵循,老實說我本來以為在全世界都是這樣,但是根據我的觀察,在台灣這個狀況比較明顯,反觀我在台灣以外的一些合作夥伴和團隊,對於 "規範" 這個事情的嚴謹度和遵守(你也可以說是死板),超過了我的想像和期待。

我舉幾個簡單的例子:
1.估時程:我常常看到,為了爭取到某一個案子,在時程評估的時候,就已經放棄架構了,我們給了客戶一個若要遵循架構就根本不可能達成的預計完成時間。
2.當進度落後:當進度落後的時候更慘,本來SA,SD花時間想好的架構,可以因為進度理由一夕之間失效,更有趣的是,這個架構可能是先前花了兩三個月決定的,但是Developer+PM可以在一天內推翻。
3.當客戶要求不合理:一樣的狀況, 有時候客戶會有一些超越常態或是超越技術可能性的要求,為了成案,往往PM答應的莫名其妙,而怪的是,最後還是可以做得出來,天知道這後面隱藏了哪些可怕的東西。

剛講到MVC和所謂的規範,可能很多人對我說的 "規範" 的定義不清楚,舉個ASP.NET開發人員應該要知道的例子,有幾個我所謂的規範簡單的具體例子就是:
1.ASP.NET頁面(.aspx和.aspx.cs 或.aspx.vb)當中,不得有ConnectionString or SQL指令。(你應該寫在一個表(不管是資料表或是對照表)當中,以便於後續維護。(但是,誰敢說自己的.vb或.cs中沒有SQL指令碼?我看是一堆吧...)
2.ASP.NET程式碼當中不該有商業邏輯,只能有處理UI的Code, 也就是說,你應該要有一個Business object。
3.超過100行的Method或Sub, Function 應該再切割。

類似像上面這樣的說習慣也好, 說規範也行,是不應該被打破的,但是,有多少因為時程關係而破壞規範的例子? 多的慘不忍睹。

在連續幾次課程中我被問到MVC之後,我的回答開始變成:如果你(或你的開發人員),無法嚴守上面這幾個規範,那就不應該去想ASP.NET MVC,因為這(MVC)不符合你的需求。

MVC是一個保持(證)系統架構清晰、具有延展性、可抽換性的開發架構,以降低維護成本提高重用性,但是如果你的Code是上面這樣的寫法,那完全不可能接受MVC的規範。

好,回來談Silverlight, 上課時,我很清楚的跟學員介紹了Silverlight RIA抓取後端資料庫的方式,大致上如下:
1.撰寫一個Business Object(包含Data Access Class)來抓取資料庫中的資訊,例如請假資料...(這邊應當是 AP層)
2.利用WCF或WebService撰寫一個Service,來調用剛才寫的Business Object,這是Service層。
3.在Silverlight應用程式當中,調用遠端的Web Service來存取並顯示資料。(這邊是展示層)

曾經有幾個學員問到說,怎麼會這麼麻煩呢?

我為什麼不能像以前寫Windows應用程式和Web應用程式時一樣,用一個SqlDataSource或是"直接"撈DB中的資料呢?

當我聽到這個問題之後大為震驚,這表示
1.原來以前大家都是在處理展示層的UI上,直接抓取後端資料?
2.原來過去大家很少撰寫Business Object或是Service,都是透過ADO.NET直搗狂龍式的取得DB中的內容?
(不過, 我欣賞學員願意問的求知慾, 只有這樣才能持續成長, 比起在心裡覺得怪怪的但總是沒問出問題的學員, 他們會進步得較快)

如果是這樣,那怎麼同樣的學員會問MVC的問題呢? 這沒道理啊, MVC的概念根本不是這樣啊? 原來,學員提到準備要導入MVC開發架構,但是他心裡其實對MVC還沒個底,並不知道改成MVC之後,比起他現在的開發方式額外要撰寫很多、很多很多的Class...

真的是 "變得" 比較麻煩嗎?還是其實是過去為了一時的便利, "省去了" 太多太多 本來其實應該要做的工作呢?

我的一個前輩告訴我,先前他對Design Pattren概念雖然很清楚,但是總是覺得彆扭,和台灣的架構師們討論起來也覺得沒那麼自然,似乎很難應用。

後來有一次,他參與國外的一個開發團隊,發現在這個團隊當中,有著來自世界各國的優秀成員,在當中討論系統architecture的時候,在會議中,每個人討論起開發架構,其中Design pattrene觀念似乎是理所當然的,像喝水一樣,很多的爭辯只會到某人提出應該要用某種Pattern來解決為止,不會有任何其他的疑問,架構和規範像聖經一樣牢不可破。

我並沒有說(我也沒資格說)怎樣一定比較好,坦白說我以前寫的一些範例也並不敢說全然依照上面的規範,只是回頭想想覺得有點感慨,當我們在討論RIA或是Silverlight的時候,好像一直講的都是你的程式可以怎樣炫、可以怎樣讓人感覺不同、有怎樣的使用者體驗...但是卻忽略了開發架構是一切的根本,為何我要建議學員考慮把一些ASP.NET的應用程式改以 Silverlight來開發,原因不是炫、是這樣的開發架構才較為合理。

Silverlight有清楚的展示層、服務層、AP層、DB層的觀念, 除了展示層之外的東西,都應該是與UI無關的,和過去ASP.NET開發人員習慣(但不應該)把所有東西綁成一坨混在一起是不一樣的。

我還是這麼說,應該把技術應用在適當的場合,技術本身有延續性,很多新技術的出現,都是因為要解決過去的一些問題,UI只是其中之一,除了UI之外,開發架構是一個開發Team的核心競爭力,否則我們的開發團隊很可能只能持續的從勞力苦工中獲取很低很低很低的毛利,很類似台灣的代工製造業現在面對的問題,開發團隊中沒有一些累積出可重用的元件其實是一件很可怕的事情...

從團隊到個人也是,過去的經驗的累積(包含知識、專案、成品、元件),會是開發人員與其他開發人員不同之處,我知道每一個開發人員現在其實都很累,面對專案、面對一些其他有的沒的,但是如果可以,還是建議大家,多花一點時間在架構上,對於開發人員來說,這應該是只有好處的。

留言

匿名表示…
台灣很多寫 .NET 的人,根本不知道世界上有 Design Pattrens 和 MVC 這種東西,
他們只在乎怎麼調整 GridView、趕快追著學 LINQ 等新技術,和窮於應付「人」的問題。

但能怪他們嗎?找遍台灣的 .NET 論壇,有看到任何 架構設計、OOAD、軟體工程、設計模式... 的討論區和論壇嗎?

沒有,一個也沒有,連官網也不例外。
匿名表示…
請問您最近有出版書籍的計畫嗎?
Silverlight 2.0 目前的中文書很少;
來詢問看看~謝謝!
匿名表示…
這個月會截稿,預計在3月隆重推出...^_^
匿名表示…
David大哥
我覺得你這篇的觀念很實際,但無奈仿間書籍很少介紹到架構以及正確觀念~我想如果你可以寫一本這樣的書籍, 相信就算是十年後, 依舊也會是值得翻閱的參考書籍.
匿名表示…
微軟剛出一本「Microsoft .NET: Architecting Applications for the Enterprise」

http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=073562609X&sid=47334

是神人 Dino Esposito 寫的。內容從 架構師的定位、UML、Patterns、DAL設計、BLL怎麼分層,到SOA的觀念。裡面最棒的一句話:
架構師不該寫程式。

小弟的消費卷剛好拿去買了一本。
匿名表示…
請問董老師,
您準備要出的新書的範例會探討Silverlight的展示層、服務層、AP層、DB層觀念這些方面的實作嗎? ASP.Net已經有MVC framework了,那Silverlight將來會不會提供?
匿名表示…
會的, 這次出版的Silverlight 書籍當中,除了基本的觀念和開發技術介紹之外,我會特別花一些篇幅介紹RIA的觀念,以及透過Silverlight開發應用程式的方式,因此相當多的範例都是以這樣的架構來開發..
匿名表示…
TO 承佑,
謝謝你的支持, 但有些書, 在台灣出是可能會害出版社賠大錢的...^_^
匿名表示…
另外,ASP.NET提供MVC framework的原因是ASP.NET距離MVC太遠了,而坊間其他一些Web開發工具(技術)卻內建提供了MVC的觀念和底層架構(還配合REST...),因此ASP.NET才需要提供MVC Framework。
但反觀Silverlight,在Silverlight架構下,你不需要特別考慮MVC,我們可以在SD階段,就以MVC的觀念來設計, 不太需要額外的底層架構配合...即使需要,自己開發一套規範的成本並不像ASP.NET這樣高
匿名表示…
David大哥
最近幾個月,從學術單位換來到了電子製造業,公司有的crm和電子商務網站是用java開發,.do(我只知道它網站的副檔名都是.do,好像是java開發的web介面程式)
感覺用起來比.net快一點,順暢一點,但我不太清楚java這部份的技術。
不過似乎部門有傾向未來開發新專案或新網站,想使用java,感覺未來公司有越來越多專案想要用java。
關於這部份,有空能否寫一篇blog介紹asp.net和java開發的差異,針對開發便利性、效率等等做個分析比較
也算是提供像我這樣只對.net熟悉技術人員,有不同的面向的認識。
匿名表示…
TO 承佑,

我在想這類的文章應該網路上隨處可見唷, 同時我也不是Java領域的專家, 所以這類的比較恐怕由其他專家來做比較好。

對我來說, 兩邊的架構在.NET 2.0(含)之前幾乎是一致的,到了.NET 3.5之後差異比較大。.NET這邊多了一些旁枝末節的發展, 例如LINQ之類...至於ORM, MVC, 這些concept本來在其他陣營也是都有...

倒是選擇性我想純粹是公司派系考量, 不時會有一些公司很挺Java, 也不時會有一些公司很偏微軟, 看起來技術原因少一些, 政治理由恐怕佔比較多的因素。

如果你.NET學的夠熟, 換成Java並沒有什麼不同的, 你幾乎可以找到相對應的每一層技術架構, 反之亦然。
匿名表示…
老師講的真的太好了!

事實上真的專案就是,
時間、成本幾乎是唯一考量,技術人員只能在這兩個考量底下,想辦法把真正好的Pattern掛個「形式」上去。

為什麼說形式?因為一開始就像老師講的,花了兩三個月弄好專案template,
最後就是一句時間內要弄出來,不然賠錢你賠,再把整個心血搗爛,用最原始的方法,日復一日。

更機車的是要你用好的pattern,卻又不肯負責,給你不合理的時間、人力、薪資,最後要你扛責任..

到最後在反打一槍,問你為什麼要用新的架構,專案有出來才是最重要的,客戶哪懂什麼是MVC,什麼是JAVA,什麼是.NET!
新技術人員訓練成本也要技術人員扛,我們甚至連BLL跟DAL都由developer設計,原因就是SA不懂什麼叫做「layer」...分析delay了,還反怪layer切不好,一個連「layer」是什麼都不瞭解的人,卻是說話最大聲的...
Kenny寫道…
我很好奇的是MVC和一般的三層式架構(UI, BRL, DAL)有什麼不同?
請原諒我的無知,我只是一個工作剛滿一年的菜鳥而已。根據我自己本身的經驗(正在做第二個專案),外國人的確很遵守那些所謂的規範,所以我也不知不覺中認為那樣是正確的觀念,文章中提到那3點範例也是我認為很正常的事情(不是強迫自己要作到,而是每天自然的會作到)。
第一個專案是遵循一個資深設計施開發的架構下去實做,不過專案已經進行到3分之2了才發現當時的DB規劃不對必須更改,這可是讓我們痛了好久(幾乎所有地方都必須更改,包含程式邏輯的地方),不知道這個算不算架構規劃的一部分?
目前第二個專案讓我成長最大,我自己負責所有的WEB APP,包含架構的設計(還好不包括DB的設計),光這個部份就讓我思考了好一陣子該如何設計出最適合的架構以及提供最好的效能,因為我知道不好的架構會讓我之後的開發遇上很多困難,只有我一個人在負責這個專案我可不想自己搞死自己啊!可惜自己工作經驗不夠多,最後還是從自己比較熟悉的3層式架構下手。不過就因為這樣讓我體悟到原來架構的規劃是這麼的重要,關係到後面所有的開發工作。
匿名表示…
to Kenny Hsu大大,
MVC嚴格來講是種概念,
ASP.NET MVC則是framework,
下面這篇文章希望對您有幫助,有簡單介紹為啥會發展出這個framework。

http://msdn.microsoft.com/zh-tw/magazine/cc337884.aspx
匿名表示…
上週在研討會中,跟一位不認識的人聊天時,他很興奮的說著董老師的新書快上市的事情…
看來不少人跟我一樣在期待著呢^^

有些觀念的東西,是需要好好建立的。
無奈在現實環境上,只能先想辦法把東西寫出來,哪有時間好好想架構的事情…

不過,也正因如此,現在寫一些Silverlight的應用程式時,糟遇到的問題就特別多丫!

===

希望下個月的研討會中,能從老師這裡學到更多東西~
匿名表示…
to 旭峰:
謝謝大家的支持, 下個月的研討會見啦~

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...