從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的核心競爭力，否則我們的開發團隊很可能只能持續的從勞力苦工中獲取很低很低很低的毛利，很類似台灣的代工製造業現在面對的問題，開發團隊中沒有一些累積出可重用的元件其實是一件很可怕的事情...

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