最近我收了一封信,我想與大家分享我的回應.
Rocky,
我們的公司將要在開發軟體的方式上轉型.我們是一間非常大的公司,辦公室遍佈全球.目前只有我所在的地方使用CSLA.如今公司其他人打算建立一個認可過的方法論"工具箱",現在我們必須保護使用CSLA的決定.從一般情況看來,我覺得這是個好主意.但就現有情況看來,似乎提供建議方案的人來與我們面談,不是為了找出我們有沒有作對什麼事,特別是我們用的東西來自於CSLA.
現在,我了解我能很好的提出質疑...但是,我認為你的幫助將非常有價值.這裡有一些有關CSLA意見的列表,我覺得我必須清楚的反駁.就個人立場我知道他們客觀上是錯的,然而,他們似乎對於CSLA有著普遍的誤解.你認為呢?再提醒一次,這些都不是我的意見,只是我從公司其他人聽來的誤解,我需要把它弄清楚.以及,有一項關鍵性的誤解是我們應該使用Enterprise Library以取代CSLA,再一次強調,他們不了解到底CSLA.NET是什麼東東.
誤解
1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.
2. 許多CSLA的功能可以用Enterprise Library達成.
3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構
4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.
5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.
6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只是後知後覺.
這些是我覺得應該要釐清最關鍵的幾項錯誤想法...你能對於我形成中的論點提供任何協助,我將大大的感激.
感恩!
Jimbo
我的回覆如下:
Jimbo,
1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.
這絕對不是事實,在COM-based CSLA與CSLA.NET有非常多且完整的更動.沒有程式碼被搬移過來,事實是CSLA .NET中的概念已經被.NET自己使用了,參考COM的部份是很有限的.
長久以來,CSLA的確到處都使用了某些OO概念.這些概念經歷了許多時間的測試都保留下來了,也證實對於設計與建構軟體非常的有價值.只因為它們由來已久就拋棄掉好的觀念是很愚蠢的.就如同因為輪子是舊有思維而把輪子丟掉一樣.
各位必須要認知到非常重要的一點,CSLA .NET與Enterprise Library是完全互補的.CSLA .NET提出一套解決方案解決了Enterprise Library未對付的問題,而Enterprise Library則提出一套解決方案解決了CSLA .NET未對付的問題.
2. 許多CSLA的功能可以用Enterprise Library達成.
再提一次, EntLib與CSLA .NET是互補的.像是日誌,快取,資料存取,系統設定.而日誌功能便在CSLA .NET的範圍之外.
而像是資料驗證,身分認證,資料繫結的支援與針對資料n-tier的位置通透性則是CSLA .NET關注的重點.
當然EntLib也有資料驗證模組,在架構上並不穩固,把商務邏輯放進使用者介面層還不如封裝到獨立的商務層.(譯者註:本人認為這兩者應該都需要,UI跟Business都需要資料驗證)
3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構
無疑的使用一個特定應用的架構是一種風險.在此事項上,任何使用CSLA .NET的組織必須清楚了解架構的本質.
然而,要明白另一點也很重要,CSLA .NET是一個使用.NET類型而被廣泛使用的架構.雖然EntLib的確更廣泛被使用,但並非複製或取代CSLA .NET所提供的功能.
如果你未使用CSLA .NET,你仍需要解決它所對付的相關問題.無論喜不喜歡,在.NET中到處都是資料繫結,資料驗證,身分認證與等等需要跨越的障礙. CSLA .NET排除了這些障礙.如同其他產品像是NetTiers, LLBLGen, Ideablade與其他的產品.有些是商業產品,有些則不是.
但目前沒有一個擁有像CSLA .NET這樣廣泛的使用者基礎.
已經有好幾個人在研討會上找我討論並指出他們寫了CSLA .NET的複製品.他們已經閱讀了我的書,不想要使用所謂"特定應用的架構"並且開始自己弄自己的東西.幾個月以後,觀察應用程式並發現到他們又重複解決了所有的同樣的問題.處理所有的同樣的障礙.並且他們用更多程式重建了CSLA .NET.通常他們因此很難過,了解到他們浪費了多少時間去重建一套已經存在的架構.
4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.
這顯然不是事實.抱歉,但是CSLA .NET 2.0在觀念上特別是為了WCF與WPF而開發的.我在微軟的技術先驅團隊中,並提供許多協助以形塑許多這些開發者導向產品的本體.我在.NET 3.0完成多年前就了解其基本的型態與架構,因此在2005年CSLA .NET已經為這些新技術作好準備.
儘管在對此產品評估的言論裡面,其他大部分尖銳的批評是合理的且考慮周詳的(雖然我清楚的反駁某些結論),這一項質疑卻完全是荒謬的且漠視了我已經花在過去四年多的幾百個小時的工作.也忽視了這些年來確保CSLA .NET提供無縫與簡單的更新路徑,從Windows Forms, Web Forms 到 WPF,以及從Web Services 或 Remoting 到 WCF.
我想提出一項挑戰,看看有沒有人能找出另一個架構能讓使用者透過簡單的修改設定檔就能從Web services或Remoting切換到WCF.並且藉由我為這些技術準備的方法我在2004與2005就在CSLA .NET中完成了這些功能.
5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.
此處有兩個觀點.
第一, CSLA是一個品牌. 無論是"以元件為基礎可調較的邏輯架構"是否仍能正確的描述(這不能)都不再重要,因為這個品牌就是它自己.換句話說,不要太鑽研它的名字 - 我被它搞的很煩.
第二, 無疑的CSLA設計用來支援n-tier的主從端架構.這樣的架構目前是使用WPF, Windows Forms與Web Forms介面建構互動應用程式最好的方式.無論喜不喜歡它,SOA有太多多餘工作負荷並且對於大多數互動性應用程式開發來說成本太高.
認為物件導向設計在面臨SOA或者workflow時會被消滅是很蠢的.事實上它們是高度互補的.
一項服務或者一個工作流的活動從定義看來都是基本功能單位.如果他們不是,那麼你就弄錯了.
實際上每項服務與每項活動是"迷你應用程式".它們實際上也是一個使用者案例,從一個物件導向設計(OOD)的觀點看來.
例如:你可以(並且應該常常)使用OO概念設計並實作你的服務與活動.所有有關於讓物件導向設計/程式開發(OOD/P)用於打造應用程式上的相關事宜,CSLA .NET都能夠讓它變的更簡單.
結論是,無論你正在打造消費服務的應用程式或者生產服務及活動的應用程式,CSLA .NET都有很大的幫助.
6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只不過是後知後覺.
事實是CSLA .NET已經能夠有大量使用者作為後盾,他們來自於微軟平台上快速增長中的更新與混亂的地帶.藉由清楚的在使用者介面與商務邏輯間的程式碼間強化邊界的輪廓,並藉由支援.NET標準的資料繫結與.NET功能的使用者介面, CSLA .NET持續擔任一個有價值的緩衝區,允許有價值的商務邏輯更容易隨著時間發展,即使使用者介面技術改變又改變再改變.
為了對付微軟平台的快速變革,我會花更多時間替CSLA .NET或者更重要的CSLA .NET的使用者建立"不會過時的技術",但明顯的要抽象化所有微軟發表的變更是不可能的,但是CSLA .NET努力保護其中最重要的以及在維護與建構上最耗成本的:你們的商務規則與邏輯.
原文見此
沒有留言:
張貼留言