從 COM(Component Object Model) 時代到 DCOM(Distributed COM)
微軟扮演了一個推動者的角色
如果說 COM 提供了一個 Windows 平台上的對象通訊技術
並且逐漸成為應用程序之間彼此通訊及互動的技術主流
那麼 DCOM 則是解決了計算機的通信和互動技術
COM 的著眼點是在於同一台計算機上不同應用程序之間的通訊需求
跨到另外一台計算機之外
就不是一開始 COM 所設想到的領域
所幸跨程序的通訊和跨計算機的通訊差異僅在於通訊協議的處理 ( 也就是定位問題 )
對於數據交換上型別差異的處理並不會因此而有區別
所以要讓 COM 的環境能更進一步延伸到跨計算機的領域
只要妥善解決計算機定位的需求
就有機會克服
同樣幸運的是
COM 在一開始的設計中完全不去碰觸跨計算機的問題
使得要在 COM 的架構之上再架上一層跨計算機的處理環境並不會去破壞到原本的架構
於是 COM 的網絡延伸版本 DCOM(Distributed COM) 就此出現
專責讓 COM 組件可以在網絡環境下持續提供服務
DCOM 最主要處理的是兩個議題
第一個議題是網絡通訊能力
第二個議題則是權限的問題
之前 COM 是在同一台計算機中找特定的組件
而 DCOM 則要更進一步去找網絡上的某台計算機
之後沿用 COM 的機制找到計算機上的組件
到了
NET 當中
跨計算機的問題同樣也需要對應的技術進行處理
NET Remoting 就是一個對應於 DCOM 的技術
它讓存活在不同應用程序域 (AppDomain
一個
NET 中的新概念 )
不同執行程序
以及不同計算機上的對象能夠順暢的進行溝通協作
在累積了長期以來分布式應用的經驗之後
微軟沒有理由把東西設計的更難用
從某種意義來說
NET Remoting 提供了比過去更易於使用的開發架構
用來來支持跨計算機的溝通作業
省卻開發人員建立分布式應用程序時必須花費的心力
不過這樣一個
出色
的分布式應用應用框架並沒有得到本來應該得到的
待遇
相對於 Java 的 RMI 而言
它更加簡單同時保持設計方面的彈性
同時擯棄了 DCOM 的一些缺點
在對於一個前後端必須以有狀態緊密結合方式進行互動作業
同時又期望呼叫和數據交換的動作上能以最有效的方式進行的環境而言
NET Remoting 是一個比較恰當的選擇方案
可是問題在於微軟本身對於 XML Web Services 的狂熱推崇讓
NET Remoting 迷失了本來屬於它自己的陣地
也就是說 XML Web Services 的過火讓
NET Remoting 忘記了自己應該承擔的角色
於是在開發者眼中成為了一個
可有可無
的作品
至少對於很多開發人員而言
在需要創建分布式應用程序的時候首先考慮的是 XML Web Services
而在於企業內部應用
特別是在可以控制服務器和客戶端平台的情況下（比如完全基於
NET 平台的應用）
Web Service 因為效率等等各個方面的原因並無法體現出優勢
從技術本身來講
NET Remoting 是一個非常出色的架構
但在商業方面
這是一個失敗
畢竟
設計一個出色的產品然後束之高閣難免
不像話
NET Remoting 恰恰是這個戰略的犧牲品
雖然擁有與生俱來的優點
不過依然生不逢時
Enterprise Services 從一個很直接的感覺來說
Enterprise Services 只是對於 COM+ 的一個包裝
從使用方式和技術實現本身而言
和 VB 或者 VC 下使用 COM+ 服務沒有本質的區別
而更多的只是在於多了一層托管代碼的包裝
讓
NET 開發人員能夠比較順利的使用這些服務的功能
相對於 J
EE 平台上的應用服務器如 BEA 的 WebLogic
IBM 的 WebSphere 或者開放源代碼的 JBoss
微軟是希望能夠在企業級應用之中分一杯羹
可是因為先天不足的原因
在企業應用中需要的事務
負載平衡
故障轉移等等技術中的表現不是那麼盡如人意
至少缺乏非常清晰的應用服務器（ Application Server ）的概念
雖然微軟不止一次的強調操作系統本身就是一個應用服務器
一個 IT 信息的基礎結構
但是從開發人員實際的使用來看
這是一個
晦澀難懂
的產品
雖然
NET Framework 改變了很多東西
但是作為企業級應用中最重要的支撐技術——事務和服務
並沒有得到同等程度的發展
我想這個也就是很多大型企業應用目前不選擇
NET 的一個理由吧
畢竟從 MTS —— COM+ —— Enterprise Services
這一路走來微軟始終不是提供一個非常透明的機制讓開發人員去控制各個環節（可能和微軟一貫以來的策略有關
只是關心最廣泛的應用而不是最高端的應用）
而
NET 中的所謂企業服務
和競爭對手提供的相當的 EJB 還是有比較大的差距
這是一個日前的微軟無法解決的軟肋
Web Service 從一開始
微軟就將其作為
重頭戲
推出
並且饒有意思的增加了 XML
然後那個
XML Web Services
就成為了
NET 戰略中一個非常重要的術語
就如微軟的白皮書所言
Microsoft?
NET 是 Microsoft XML Web Services 平台
微軟通過
NET 來改變現有的互聯網絡結構
Windows 正在走向過去
這樣的宣傳是在於希望各個子系統之間的通信完全基於 Web Service
那樣的話
作為 Win
開發人員一直困擾的組建注冊
分發等等一系列問題都能夠得到解決
並且能夠用更多的語言更多的平台去開發應用
一切皆是 Web Service
這是一個冒進的舉動
至少對於
年以前的世界
而這四年以來
雖然 Web Service 有很多很多的優點可以讓我們
歌功頌德
但是不是
萬金油
比如一直稱垢的性能和安全問題也阻礙了 Web Service 一統天下
於是其他分布式應用架構在特定的領域依然能夠有自己的生存空間
這一次
微軟高估了 Web Service
雖然目前的
NET 是實現 XML Web Services 最好的平台
Visual Studio
NET 也提供了從上至下的包裝
讓開發人員完全可以不關心協議的底層實現
比如 SOAP
比如對象序列化
比如 WSDL
因為一切的一切都可以在 IDE 中自動完成
我們不否認因為
NET
Web Service 從概念已經走進應用
而 WSE
的出台更加 Web Service 具備了互操作能力
不過依然無法改變開發人員的觀點
只有在企業外網應用集成或者內部異種平台整合的時候才能夠體現出優勢
在於需要高度響應和服務支持的應用方面
Web Service 只是一個臆造的神話
ASPNET 我們無法否認
這項技術對於開發人員而言是一個顛覆性的改變
從靜態的 HTML 到 CGI 再到 ASP/JSP/PHP 時代
我們都必須去了解 HTML
了解 HTTP
對於高水平的開發人員而言
需要掌握的還遠遠不止這個
在腳本橫行的時代
我們必須很清楚的去了解實現的各個細節
包括 HTML
JavaScript
CSS
還有和服務器相關的 Request
Response
最直接而言
開發人員必須嚴格控制所有 HTML 及其相關內容的產生
腳本帶來的只是一個相對於 CGI 層次更加高級的
自動化
罷了
然後
ASP
NET 將這一切完全改變
WebForm 讓 Web 開發人員能夠和 Windows 開發人員一樣處理頁面事件
同時可以完全的訪問強大的
NET Framework 類庫
而且預先編譯機制解決了 ASP 一直以來的效率低下問題
而在服務器端的設計
在原先 ISAPI 的基礎上從新實現了 HttpHandler 和 HttpMoudle
從而為開發人員提供了高度擴展的可能
而日前比較成熟的 WebLog 引擎
Text 正是這些技術的經典之作
XML Web Services 的內置集成則使 ASP
NET 成為 Web Service 應用的最好實現
日前市場上相當大部分的 Web Service 都是基於 ASP
NET 的
在這點方面 ASP
NET 已經遠遠超出 Java 社群的技術
包括 JSP
包括 Struct
包括 JSF 還有其他相關的 Web 應用技術
在 ASP
NET 都能夠得到非常好的集成
我們不可能否認這個事實
相當大一部分（我個人認為是大部分）的開發人員轉向
NET 是因為 ASP
NET
對於 ASP 開發人員而言
ASP
NET 提供了更加強大的功能
很多在 ASP 中必須依賴組件技術來解決的問題比如文件上傳在新的平台上已經成為內置支持
當然更加重要的是依賴 Visual Stuio
NET 強大的集成開發環境能夠成倍的提高生產率
而另外平台的開發人員轉向 ASP
NET 我想也是因為彈性的設計及其便捷的開發
我相信沒有太多人會懷疑 ASP
NET 已經走在 Web 開發的最前沿
當然
任何事情沒有絕對的完美
在
NET Framework
( 也就是
NET 的第二個版本 ) 之前
太多的 Postback 也是讓開發人員抱怨之處
而且采用 WebForm 的開發方式讓很多開發人員不是那麼容易的處理客戶端腳本
所有的事件實現都是依賴於 ViewState
因此在低帶寬下的網絡應用
不斷地提交也讓有些用戶感到
惱火
這個世界沒有絕對的完美
但是會一點一點走向完美
也許 ASP
NET
就有太多東西值得期待
ADONET 相信大家不會忘記 ADO （ ActiveX Data Object ）
我想 Windows 上面數據庫開發流行它功不可沒
通過統一的接口來實現對於數據庫的訪問
從而屏蔽復雜的數據庫訪問協議
而到了
NET 時代
ADO
NET 進一步將數據訪問
進化
不要以為 ADO
NET 只是 ADO 的一個升級
在 ADO 的技術上提供了一個托管類庫
除了都是數據訪問框架
其他沒有太多本質的關聯
雖然 ADO
NET 帶來的震撼遠遠不如其他技術
可依然有很多東西值得我們去欣喜
畢竟創新總是一件好事情
何況是這個最成功的軟件公司帶來的創新
那麼我們就來看看到底帶來了什麼
．除了提供了傳統 ADO 的 Connection
Command 以外
我們意外的沒有看到 Recordset 這樣的對象
而是提供了 DataReader 用來處理向前滾動的數據訪問
最最重要的是加入了 DataSet 這樣的概念
因為如此
我們能夠實現很多數據庫應用中需要的
Disconnected Application
能夠實現
InProc
Database
而這一切
通過 DataSet 能
From:http://tw.wingwit.com/Article/program/net/201311/11599.html
