非常同意現在的系分、高手都很熱衷於趕時髦，或曰“浮躁”。我也見過非常非常之多人是在為了三層而三層，把簡單的問題復雜化，把沒必要做成三層的應用特地改成三層，結果得不償失，事倍功半。
但對王兄後面的一些技術性分析，我覺得還是有值得商榷之處。
首先，李維所說的：DCOM 的連接速度較SOCKET CONNECTION 慢， 但是連接完成後， 傳輸數據較SOCKET CONNECTION 要快。我覺得基本正確。要注意一點：這裡的Socket並非指Socket通訊，而是指Borland的SocketConnection。
問題在於王兄把DCOMConnection和DCOM混為一譚了。DCOM應用是一種相當於是遠程的Automation應用，它是通過ORPC協議來傳輸IDispatch接口實現的。所謂的DCOMConnection便是基於DCOM的ORPC協議來傳輸MIDAS的IAPPServer接口（它也是派生自IDispatch接口），而MIDAS（不止是MIDAS，DNA也一樣）並沒有限制DCOM連接（即ORPC）的服務端必須是DCOM應用，後來的MTS、COM+無一不是基於此，即便是現在.Net的remoting也是基於此，它是在成熟的標准RPC基礎上，結合了Windows的安全機制發展的起來，最關鍵一點，它的底層協議也是TCP/IP（ORPC用了UDP和TCP兩個協議）。王兄所謂的淘汰之說，應該是指DCOM應用，而不是指DCOM連接吧。
不可否認，MS設計ORPC協議是完全基於Windows的域用戶安全機制，這決定了它有很多的限制，特別是因為用了動態端口，所以基本上是無法穿過Firewall（不表示不能，只要打開Firewall的全部端口即可，但這樣的話Firewall就形同虛設了），但也還有其它辦法可以解決，典型的就是MS提供的基於IIS的CIS（COM Internet Services）技術，此外便是Borland的SocketConnection和WebConnection。
從本質上說這些穿過Firewall的技術都是所謂的Tunnel技術。即通過一對代理把ORPC的請求和響應轉為通過別的協議傳輸。其中CIS和WebConnection的本質都是用HTTP協議作為中間協議，而SocketConnection則是用TCP協議。如下：
DCOM ClIEnt ==[遠程接口調用/ORPC]==> Server（DCOM/MTS/COM+）
DCOM Client ==[本地接口調用]=> ClIEnt Agent(SocketConnection/WebConnection etc.) ==[中間協議：TCP/HTTP]=>Server Agent(ScktSrvr/HttpSrvr etc.)==[本地接口調用]=>Server（DCOM/MTS/COM+）
上面一個是標准的DCOM連接，下面則是Tunnel連接，因為Tunnel多了很多中間步驟，所以數據傳輸性能一定比較差。但為什麼連接速度反而比DCOM快呢？因為ORPC有安全性約束，在連接時需要身份驗證，而用了Tunnel後，兩邊都是本地接口調用，不用安全身份驗證，所以連接速度比較快。但這樣的話就需要自己處理安全問題，如SocketConnection提供了Interceptor技術，而WebConnection則需要借助於SSL。不過據我所知，絕大多數做這兩種應用的人都沒有考慮過這個問題（據說有人用代理獵手在網上搜211的端口號，居然找出一堆的地址，汗啊）。
正好前不久給一朋友幫忙，他為了安全考慮，需要改造WebConnection，所以對它的實現機制剛好還是比較熟的（不然MIDAS有幾年沒有用了，快忘記著差不多了）。王兄說WebConnection會導致效率大幅下降，這我同意，因為在WebConnection中需要對COM請求的數據進行Marshall並編碼為HTTP協議所需要的文本格式，到了httpsrvr中又要把HTTP的文本轉成本地COM調用。相對來說，SocketConnection的二進制數據效率肯定比HTTP的文本要高，更何況相比WebConnection用的HTTP這樣的應用層協議來說，SocketConnection用的底層的TCP協議，性能上也要好。但如果用了SocketConnection就必須要在防火牆上專門開一個端口供其使用，對於一些只能訪問Web的防火牆，就無能為力了。
至於基於XML和HTTP的SOAP/WebService，我也同意王兄的看法。基本上它的大多數優點，WebConnection都有（只是通用性和標准性不如SOAP），而且WebConnection用的BASE64編碼無論在時間效率和空間效率上都遠高於XML編碼。個人認為，如果不是必須要與異構系統互聯，SOAP/WebService還是應該避免的。
但王兄認為HTTP效率低下就完全不可取我不敢苟同。在一些情況下，用犧牲效率來換取高度的靈活性還是值得的，至於王兄所說的查詢出數M的數據，對於現在的網絡來說，問題並不是很大，就算數據量再大也可以通過減少每次傳輸的記錄數來解決，畢竟使用客戶端的用戶一次能看的數據也是有限的。
拋開WEB防火牆的苛刻要求，SocketConnection不論是在性能上還是在靈活性上應該說都是比較好的選擇。但遺憾的是，Borland提供的SocketServer並不具有工業應用的能力，具體的王兄已經分析得很細了，我就不再贅述。但王兄因此否定SocketConnection我覺得不太妥當。
畢竟對於Borland來說ScktSrvr是一個隨DELPHI/BCB免費提供的小程序，不可能對它要求太高，拿Tuxedo來比是不公平的，Tuxedo可是BEA的主要賺錢產品之一，單一個Tuxedo就比DELPHI要貴了，沒有理由要求Delphi免費配一個跟Tuxedo相當的產品。而Borland提供了ScktSrvr的源碼意義也正是在於：如果你需要很高的性能要求，完全可以自己參照著源碼用完成端口之類的更好的方法去修改它。
當然，就目前的情況來說，MIDAS並不能算是一個非常好的多層解決方案，不可能指望用一種多層技術去處理所有的多層應用情況（即所謂手裡有一把錘子，看什麼都是釘子），但MIDAS總算是所有多層技術中，最簡單的之一了。
歸根到底一句話：技術不是根本，使用技術的人--這才是根本。
