終於瞭解了下.net 和 j2ee的區別_C#教程

關於.NET技術與Sun公司的Java2企業版（J2EETM）相比較，許多客戶都想瞭解Microsoft公司的觀點。由於以下的幾個原因，.NET和JEE的比較有點棘手：

1)   一般來說，Windows .NET Framework是Microsoft的Windows系統中經過精心定義的技術部分，而J2EE則是一個書面的協議。如果不局限於學術方面的討論，換句話說，就是在幾個應用平台上討論這個話題的商業價值，那麼僅僅比較J2EE和一個實際應用的工具是沒有意義的。

這樣實際應用的工具如：IBM公司的WebSphere應用服務，BEA的WebLogic服務或是其它類似的應用服務。

要想得到令人滿意的分析，只有進行產品之間的比較，例如比較開發效率。使用J2EE，開發人員需要建立4個組件來建立一個單一的EJB。表面上看來，這隻不過是為開發效率付出的一點代價而已。但是Java的一些開發工具隱藏了一些開發技巧，降低了效率。另一個例子，J2EE的部署體系十分複雜難解，類嵌入 JAR，而JAR嵌入WAR，WAR又嵌入EAR。但是在一定程度上，有些工具能自動完成部署進程。上述情況導致決定一個應用服務商業價值的關鍵因素開發效率因不同的銷售商而有差異，這主要取決於開發工具的效率。

2) 關於"J2EE全明星隊伍"的問題。當比較.NET和J2EE所有組件的集合時，這個問題就產生了。例如，分析者考慮開發效率時可能碰到下列問題，A公司的產品， B公司的應用服務程式， C公司的安全規則， D公司簡便安裝， E公司決定價格。所有這些都可能和J2EE有關。集合上述這些特徵屬性，J2EE工具看起來還行：價格便宜，安裝簡便，速度快，安全性高，有超快取，並且有好的開發工具，等等。但這些都無關痛癢—因為不可能同時獲得所有的這些特性。事實上，一次只能得到一個準確的特性。因為這些產品來自不同的公司，它們不可能合作無間。例如，IBM公司的工具不能和BEA公司的WebLogic服務同時工作，因為後者是用的Oracle公司的緩衝引擎，而 Oracle的引擎不能用Iona的價格獲得，等等諸如此類。人們有時候會誤將"J2EE的所有特性集合"作為比較的基礎；但這是不合理的。客戶需要的是知道一對一，產品對產品的比較。

3）比較.NET和J2EE而忽視其它應用平台是十分重要的。J2EE是僅關注應用程式伺服器的規範。但是絕大多數客戶對下列這些感興趣：應用程式伺服器，連接埠，商務服務器和分析工具，資料庫，分離資料和流動性，資訊代理，應用程式集合，容量管理，智能用戶端等等。作為對客戶要求的回應，這些因素應該統一工作，所有的主要銷售商應該推行整合的平台。例如Microsoft的平台（包括Windows系統的用戶端和伺服器，Windows .NET Framework，Visual Studio.NET Framework，和Microsoft企業伺服器）；BEA的WebLogic平台；IBM公司的WebSphere平台；Oracle的平台；還有Sun公司的一個平台。將精力集中在這些平台的一個難題（應用伺服器）上將會導致一個類似"樹林和森林"關係的問題。這樣的一個比方是合適的，但是它應該被考慮到一個更廣闊平台的一部分。

從Microsoft的角度來看，和那些不常見的警告相比，這些是Windows .NET Framework和基於J2EE的產品的關鍵性的異同點。

相似點

1）  Windows .NET Framework和Java都有一個受控的運行時環境，它不但將原始碼轉換成中繼語言，而且將這些中繼語言編譯成本地的可執行代碼。兩個環境都支援磁碟重組、動態類載入和異常處理等。

2）  .NET和Java都倡導和支援基於組件的設計、多態性、繼承和介面等，也提供基礎類庫來執行I/O、XML處理、帶有串連池的資料庫接入、文本操作與網頁指令碼編寫等。

3）  兩者都經過特有的銷售商的產品進行發布。J2EE規範自己是"銷售中立"的，但實際上那些遵從規範的產品都必須實現規範外的特性，例如管理特性或是展開特性。因此，這些產品必須是對應特定的銷售商。例如Microsoft公司的Windows和.NET系統。

4）   Windows .NET Framework和基於J2EE的產品都和第三方的產品一起工作。例如，在後端資料庫領域，.NET和基於J2EE的應用程式能訪問儲存在Microsoft的SQL伺服器、IBM的DB2、Oracle，Informix、Sybase等伺服器裡面的資料。再舉一個例子，.NET和基於J2EE的系統能訪問流行的資訊中間裝置，如Microsoft的MSMQ或是IBM的MQSeries。同樣，也包括檔案系統，第三方開發工具，代碼版本系統，防火牆等。

不同點

1）  原理

J2EE是一個單一語言的平台，關注跨平台的可移植性。這就意味著，要利用J2EE，設計方案能使用多個作業系統其中的一個，但開發人員必須接受關於Java的培訓。Microsoft提供的.NET構架作為Windows系統的一部分。開發人員能使用多種語言，並且效率很高而不用進行一種新語言的重新訓練。但.NET Framework是 Windows系統的一部分。

2）  寬度和廣度

a.       .NET包括代碼、產品、工具和構架，來利用網路上全部的計算資源，包括裝置、個人電腦和伺服器等。.NET使所有的這些裝置能經過標準通訊協議全部串連在一起，即所謂的"XML WEB服務"。（.NET應用程式可以和任何一個系統串連，無論系統用什麼語言和平台，甚至是J2EE。只要目標系統遵照XML WEB服務標準。）.NET模型是廣泛的分散式運算，它和許多代碼互相通訊並交換資訊。

b.       J2EE是面向伺服器的模型，它並不開發網路上的智能和計算功能。總的來說，基於J2EE的產品只支援伺服器端的應用程式。J2EE一般把PC只看作是一個HTML的瀏覽器，而將這些裝置認為是啞終端。至於 XML WEB服務，現有的協議標準支援分布式的計算，現有版本的J2EE規範並沒有提到XML WEB服務的問題，但是基於J2EE的產品在添加了附加裝置後也可以支援XML Web服務。然而，添加附加裝置也就意味著有嚴格的限制。例如，還不清楚現有的規範是否允許EJB調用Web服務，雖然Web服務的組件能調用一些EJB程式。

3）  編程模型的一致性

Windows .NET Framework提供了一個跨伺服器、PC和其它裝置的一致的、面向組件的模型。而J2EE提供EJB作為伺服器端的組件模型；為用戶端或是本機群組件建立開放的完全用Java編寫的API；為使用者介面提供servlet；也為行動裝置提供另一種不同的模型。甚至在EJB內部也有至少3種明顯不同的子模型，每一種子模型都有不同的語言定義。

 

Microsoft的.NET編程模型與Java平台相比較，在各種伺服器和用戶端上有更好的一致性。J2SE是基於開放的完全用Java編寫的API，而J2EE是基於Java servlet和EJB。

DH Brown, 2002年7月

 

4）  功能

a.       Windows .NET Framework 提供一個能識別版本的類載入器，這就意味著應用程式的開發人員能確保他們開發的應用程式在一部分代碼已經更新的情況下仍能運行。而Java和J2EE（現有的）沒有版本識別的類載入器，這就意味著開發人員和管理員不能保證代碼被執行時是正確的。或是說，開發人員只能靠運氣來保證這一點。

b.       Windows .NET Framework 顯示了語言層面上的類屬性—這就使得編程更加簡單。例如，在原始碼中只用一個簡單的屬性就能把.NET組件標誌為處理模式。或者說，一個.NET組件和 XML的序列化可以在一個屬性中被定義。這個機制大大簡化了許多編程任務。而Java不顯示語言層上的類屬性，雖然Sun公司考慮到要修改Java語言來改變現狀。這種變化估計在兩三年內才能第一次實現。

c.       .NET還支援分離資料訪問，這主要用於在行動裝置或是偶爾連網的場合裡啟動並執行應用程式。資料能被離線操作，接著再和起始資料重新同步。而不論是J2EE還是J2SE現階段都不支援分離資料訪問，需要這項功能的 J2EE開發人員必須自己寫"plumbing code"。

d.       為建立基於網路的使用者介面， Windows .NET Framework提供基於事件的模型，這些模型類似於流行的Visual Basic中的智能用戶端模型。ASP .NET 模型使得建立、發布和維護一個基於網路的使用者介面變得更加容易。與之形成對比的是，J2EE在JSP中不支援這樣的模型。有一些第三方的擴充程式部分彌補了這些功能，但是它們的實用性和簡便性不能和ASP .NET相比。作為一個推薦的J2EE附加程式，Java Server Faces可能做到這一點。但這個附加程式並沒有包括在J2EE的1.4版本以前。而要獲得銷售商的支援，則又需至少一年的時間。

e.       J2EE支援一個對象相關的資料映像模型，它被稱作EJB Entity Beans。這樣是為了允許開發人員更容易地從一個相關的資料庫建立物件模型。然而，實際上把這個想法編程實現卻要面對下列問題：

Ⅰ. 易用性：當那些熟知的、正規定義的、被廣泛支援的結構化查詢語言 (SQL)（SQL）和開發人員的資料相互作用時，開發人員不得不放棄它們，而使用一個被稱為EJBQL 的弱定義查詢語言。和SQL相類似，EJBQL的功能並不強大（例如，在現有的規範中，它沒有ORDER BY的語句，這樣開發人員就沒法使用特定資料庫的 SQL擴充），而它的語義也沒有被正規定義。還有，在對象間建立聯絡和附屬關係十分困難，而且在對象間和XML以及後端之間的資料翻譯是手動控制的。

Ⅱ.效能：基於EJB系統的效能仍是一個未知數。沒有提供公開的基準。客戶反映，得到的效能遠遠偏離了Entity Beans，並且轉向一個更直接的資料存取原則。這是EJB Entity Beans沒有被廣泛使用的一個關鍵因素。

在Windows .NET Framework 中，資料訪問是基於資料集比較的。資料集儲存了相關資料的一個子集，它由一個或多個SQL查詢語句描述。資料集中的資料可能儲存關鍵的聯絡，並且開發人員能直接對資料進行操作，能將資料轉換成XML格式和上次操作的類型，能使用標準的SQL過濾資料等。總而言之，相對於EJB Entity Beans，. NET的資料集模型提供一個更豐富而且簡單熟悉的途徑。

5）  簡便性

a．  配置：對於J2EE，配置是由部署描述資訊獲得的XML格式的檔案，它們和實際執行的商用邏輯代碼有明顯區別。這種方法有很多問題。第一，考慮到特定類的中繼資料，有些代碼中的改變和中繼資料中的改變是相互依賴的。兩個獨立檔案的同步性要求有可能產生錯誤。第二，考慮到應用程式層的中繼資料，在J2EE中，沒有可以從一個程式繼承中繼資料到另一個程式的途徑。與J2EE不同，Windows的.NET構架包括了這個功能，使得可以在原始碼中直接向類添加屬性，這樣就不會產生第一個問題。 Windows .NET中的中繼資料模型允許客戶自己添加擴充程式，這樣開發人員就可以編寫和使用自己的屬性。為了在Windows的.NET構架中配置外部中繼資料，這個功能被包括在設定檔的分級系統中，它能從父系統中繼承屬性，這樣每個檔案會很小，它只記錄改變的設定。這就避免了J2EE模型的第二個問題

b．  資料庫連接池Windows .NET Framework中，是根據需要自動建立和管理這些池的。而在J2EE模型中，串連池必須被明確配置和管理。

c．  XML Web服務：在.NET中建立一個XML Web服務就像在類中添加一個屬性那樣簡單。有些基於J2EE的產品也想在Java中類比這個功能，.NET提供更簡單的方法來建立和使用可由雙方共同操作的 XML Web服務。

d．   部署：在.NET中，要部署一個應用程式，管理員只需要拷貝檔案。而在J2EE中，管理員必須將很多編譯檔案和JAR、WAR以及EAR綁定，然後在一個特定的伺服器部署工具中解開並運行它們，接著拷貝結果檔案。這個多步部署過程意味著典型的編輯/編譯/調試迴圈被大大延長了。此外，由於動態載入類過程中的一些變化，更新一個簡單的類常常需要重新啟動基於J2EE的伺服器。

 

雖然許多公司選擇Java作為企業發展的策略平台，但它們的使用卻由於J2EE的複雜性而受到阻礙。Meta Group，8月

 

6）  成本

a．   為了部署，運行在Windows .NET Framework之外編寫的伺服器端的應用程式需要一個Windows Server的許可，這比三個遵從J2EE的商務服務器中的任何一個許可都便宜很多。包括四個網路伺服器的系統部署費用的差別可達到數十萬美元。例如， Microsoft Windows Server 2003（企業版）的一個四機器系統（每個有四個pc）的許可費用不超過16，000美元（這考慮了零售因素）。而WebSphere Application Server 5.0在同樣的系統中每台pc的許可費用達12，000美元，這共要192， 000美元。這個比率是12比1。大多數基於J2EE的商務應用程式伺服器的價格都和這類似。（這假定了效能相等。然而實際上Middleware公司 2002年10月的報告顯示，一個建立在Windows .NET Framework上的應用程式的效率是建立在同樣流行的基於J2EE的伺服器上的程式的2-4倍。所以實際上價格的優勢遠高於12比1）有很多免費的，基於J2EE的開放源應用伺服器，但是它們並沒有J2EE-compliant的商標。還有關於檔案和產品的問題：需要產品之間的比較來討論采許可費用。

b．  為Windows .NET Framework開發工具的費用也更加低廉。Visual Studio .NET是.NET的整合開發工具，它的許可費用大大低於商業化的J2EE銷售商制定的開發工具的費用。並且在業界，Visual Studio .NET作為最佳開發工具贏得了一系列的大獎。評估過Visual Studio .NET和其競爭者的客戶都說，相對於最好的Java工具，Visual Studio .NET開發效率更高（See Giga，2002年6月）。

c．   使用Windows .NET Framework的開發和維護費用更低。專家認為許可費用並不是一個項目的最大開支。典型的軟體開發和維護占項目總費用的50-80%（Glass，2002；Kemerer，1995；Gartner，2001）。Middleware公司2002年10月的研究表明，在Windows .NET Framework上一個給定的應用程式開發相對於J2EE，只需要1/3的代碼。代碼越少就意味著維護更加簡單。

總結

 

顯而易見：正確的產品選擇決策不可能不評估實際的產品。對比Microsoft Windows Server及 Windows .NET Framework和J2EE（Sun公司的規範）是有價值的，但是這樣的努力缺少實際產品的評估。然而，還是可以從中得出一些結論：

1）  J2EE展現了一個以伺服器為中心的原則，並將重心放在EJB和解決"相關對象的映像問題"上。J2EE在支援 XML和Web服務上已經落後了。Windows .NET Framework的原則則是通過協議標準和XML、充分利用伺服器、介面和裝置的的大規模分散式運算。

2）  相對於編寫在Windows .NET Framework上的程式，J2EE應用程式需要更多的代碼來執行相同的任務。

3）  J2EE的管理和部署模型更像是一個主機模型，它關注保護和限制稀有的計算資源，按比率使用。而Windows .NET Framework展現出的原則是計算資源是廉價的，而且將更加廉價，但是部署能力將保持大部分昂貴的資源。

總之，如果一個項目要求必須從幾個作業系統中選擇一個作為部署平台，而不考慮開發成本；強制（並且重新培訓訓練）開發人員使用單一的程式設計語言來執行這個項目，從而代碼的版本問題就不再重要；重要的是配給和限制相對便宜的計算資源；這樣使用昂貴複雜的開發和維護工具就顯得順理成章；而編寫更多的代碼也有其優越性 -- J2EE也許是一個不錯的選擇。

然而，如果商業目標顯示最佳化的開發效率是重要的；低廉的性價比更符合要求；通過通訊協議的標準獲得的可相互通性有較高價值；大量支援基於介面的應用程式和移動的應用程式是重要的；更感興趣的是易擴充性—這樣的話，建立一個 Windows .NET Framework上的Windows Server應用程式是正確的選擇。