透視和調整你的企業和商務系統（Ⅴ：Solution、Architectures）

小氣的神 2001-10-15

    好了，我想在這一篇之后結束整個的話題，似乎應當有些結論，但可能每個人面臨的具體情況不同，環境也是不同的，所以只能算是感想吧。dotNET中有些特性讓人非常振奮和喜歡，但我們不可能總是利用新技術重新開始構架我們的需求和應用，無論是遷移還是改造都需要我們認真的審視和考察，構建程序和代碼，往往開始的一個決定是重要的一個。不過這一點，往往是陷入泥潭中才想到的(haha)。

    先交代一下整個的環境和需要用的的軟件：
1．   Windows 2000 Advanced Server SP2(英文版)
2．   Windows 2000 Advanced Server SP2(中文簡體)
3．   Microsoft SOAP Toolkit 2.0 SP2
4．   Microsoft Visual Studio 6.0
5．   Microsoft SQL 2000 (中文簡體企業版)
6．   Microsoft Visual Studio.NET Beta 2 (英文版)
7．   Microsoft Visual Studio.NET Beta 2 (中文簡體)
8．   Microsoft IE 2600 （英文版）
三部機器前面我已說明了，henrysvr上是英文的W2K和VS.NET，Dereksvr上面是中文簡體的W2K和VS.NET.

最后的體系結構也被調整成這樣（如下圖），在我想像中這樣似乎對目前的系統影響最小，原來的應用的構架不用發生變化，新的需求可以有一個新的起點。而且如何實現WebService這一層，你可以根據上面的討論來具體決定。MS的Mary Kirtland（很熟悉吧）有一篇文章《A Platform for Web Services》非常不錯，特別是結尾的那幅roadmap_1.gif一定不要放過，藏寶圖一張。







至于最終的dotNET的體系結構我認為還在變化的，但有一些是可以肯定的，比如dotNET比以前DNA結構更加分布式而且更加松散；對程序員來說實現DB和Biz層也有了更多的自由度，不會象以前那么生硬。大凡應用程序的體系結構都如此，提出一種新的需要時間，深入理解需要時間，開始應用需要時間，真正應用廣泛被人們接受又需要一段時間。
說明和結論：
1．   上面所討論的都是基于這樣一個前提：你已有一個系統或應用系統（最好是Window DNA結構的），你是想改造和做調整使之利用上dotNET技術。如果對你來說，一切都是全新的，那么上述中互操作的部分對你有幫助，畢竟Window DNA結構和新的dotNET的程序體系結構是不同的，請按新的體系結構考慮，兩個體系的數據層和商業邏輯層的劃分已有了很大的不同。
2．   我沒有考慮或說針對防火墻進行考慮和測試，實際應用中，忽略防火墻可能是致命的。也就是說特殊的防火墻部署可能導致上面所說的結構不能成立。比如單防火墻，防火墻內又關閉Http和DCOM的端口。
3．   由于dotNEt和VS.NET目前都是測試版，所以有關安全、性能和發布時間都是保密和受條款保護的，那么也將無法針對性能等與已有的COM+/DCOM或Java做比較或測試。
4．   整個的討論沒有涉及到dotNEt的另一項技術:Remoting,這也將是一個考慮的因素和技術熱點，不過上面的討論覆蓋了Remoting服務于所有可能的客戶端和服務器端的組合情況，效果上是類似的，但具體實現上是有許多不同的。Remoting技術對于遠程的對象或組件可以控制得更加深入和具體一些,交互性更好。
5．   比較明顯的感受是dotNET體系下，不同平臺之間的通訊和跨平臺訪問似乎已經解決了。XML重要性加強。那么以后可能帶來的問題是：如果你是開發人員，你將如何選擇自己的平臺。你將在什么平臺上編程？
6．   Windows平臺下的dotNET和目前的COM、COM+、DCOM等的互操作性很好，在兼容性上MS放棄了一些，但是互操作方面替用戶考慮了很多，同一個問題可以有幾種方式來完成，關鍵是你采取那一種方式來達到。這讓我想起Anders Hejlsberg有關”Interoperability”的那段描述(http://www.csdn.net/develop/read_article.asp?id=9615)。憑這一點MS還是可以贏得眾多的程序員肯定。
7．   對于模型的選取上，我只用了最基本的邏輯來模擬，實際情況遠比這個復雜。再說沒有考慮部署，整個Windows環境下的COM+和組件部署其實是最麻煩和需要足夠勇氣的事情。另外有些組件的邏輯應當復雜一些（比如多些組件）或實際環境復雜些（比如多分布到幾臺機器上）這樣可能會更好一些。
8．   整個過程我們考察了Server是dotNET，客戶端可以是VB或目前的技術；服務器端是COM/DCOM，客戶端是dotNET的等各種組合，害怕離題太遠，所以少了客戶端和服務端都是dotNET的情況。不過焦點似乎最后還是回到了WebService。

感謝你花時間看了這篇文章，希望在你面對新老系統，做一些很重要的決定：維持原狀還是重寫；如何構建如何開始這樣進退兩難又必須做決定的問題時有所啟發和幫助。最后讓我用Anders Hejlsberg的話作為結尾吧：
“We@#ve tried not to take an "ivory tower" approach to engineering C# and the .Net framework. We can@#t afford to rewrite all of our software. The industry just can@#t afford it, especially now when we@#re moving on Internet time. You@#ve got to leverage what you have, and so I think interoperability is just key. We focused hard on giving programmers all of the right solutions for interoperating with Internet standards, such as HTTP, HTML, XML, and with existing Microsoft technologies, so you don@#t fall off a cliff the minute you find that something isn@#t provided by the new .NET environment, or when you realize you want to leverage some existing API or component. You@#ve seen all the COM interoperability that we have built into the language and into the common runtime;”
---- Anders Hejlsberg
 

原文轉自：http://www.anti-gravitydesign.com