淵源：
Java的J2EE在1999年形成了其成熟的架構，並且到今天已經有相當成熟的經過檢驗的企業應用系統。而.Net究其淵源是源自微軟以前開發企業應用程式的平臺DNA（DistributedNetworkArchitecture），其中包括了許多已經被證實的技術，並且這些技術已經在產品中得到實現，包括微軟的事務伺服器、COM+、訊息佇列、SQL Server 資料庫等。而對於擴充套件性，廣為業界接受的事實是.NET平臺的擴充套件思想是基於軟體的橫向擴充套件，而J2EE平臺的擴充套件思想則是基於硬體的縱向擴充套件。這也符合微軟和Sun各自的產品利益。但是我們還需要細看這個問題，.Net技術源於DNA技術。眾所周知，DNA技術可能能夠解決部門級應用的問題，但是在大型企業應用中就不是那麼適合了。其實，從微軟這家公司的歷史背景就可以看出這個問題，微軟從來不是一個老牌的企業級解決方案的提供者，它是從DOS、Windows等桌面作業系統起家的，在購買了一個企業級作業系統開發出Windows NT後才開始進入企業級解決方案市場。與IBM、HP、Sun等一直從事企業級應用的提供商相比，其技術和支援力量還顯得稚嫩。尚沒有大多的成功案例和解決方案。而J2EE 卻是這些企業級解決方案的提供商所力推的，所以J2EE在企業中有大量的成功案例和解決方案。這些可以從世界各種大企業的IT應用系統的實際情況可以看出。世界上大多數企業的IT系統中，使用J2EE技術的遠遠大於.Net。可以這麼說，.Net技術尚沒有太多比較成功的實施案例。
未來的考驗：
Java可以勝任未來的考驗，或者說能夠導向未來。這樣你現有的程式碼將不會過時，為什麼？因為我能執行Java在今天和將來的計算機上。你不能確保微軟的.NET也能夠做到這一點。一個鮮活的例子就是他們對VB6的支援，現在VB6已經過時了。
適用範圍：
兩者都能夠達到企業級應用的需求。但是I/O處理和執行緒排程從本質上來講應該由底層硬體和作業系統來解決。J2EE支援眾多的硬體和作業系統，單從這點來講，都比.Net技術有優勢得多。別的不說，大型計算機的I/O處理能力和執行緒排程能力是其他任何機種所無法企及的。而大機上目前只能執行J2EE，不能執行.Net。光這一點，就說明了在這個方面J2EE優於.Net技術。
.net照顧中小型應用毫無問題，而且開發速度快，作為使用者，付了錢很快能看到回報。大型應用，由於它只能應用一個平臺，甚至低層硬體只能選擇Intel的系列晶片。而不能在大機、Unix以及Linux等系統上使用，所以應用範圍有所限制。
資料訪問：
J2EE 和 .Net 已不同的形式支援資料的訪問。JDBC和ADO一樣和所連線的資料庫無關，並且通過連線，命令語句和結果集來對資料進行操作.所以屬於中間層次的 API.更高一級的資料封裝和資料管理是通過實體EJB (entity EJB)來完成的.基於容器管理的實體EJB使開發更快捷，管理更方便.事實上，由於實體EJB的load()和store()方法的同步機制，將大大緩解因併發而使資料庫產生的瓶頸.也可以採用不屬於J2EE規範的第三方資料訪問工具，象WebGain的 TopLink。
而微軟的.NET的資料訪問工具則由基於XML的ADO.NET代替了基於COM元件的ADO.任何以XML為輸出的資料來源都可以作為 ADO.Net 的資料來源.相應的結果集升級為資料集 (DataSets)，命令語句則升級為資料集命令(DataSetCommands).從形式來看，微軟的ADO.NET更新潮和時髦一些，基於XML的特性使其可以處理極其豐富的資料來源，並且，因其構架在HTTP協議之上，易於穿透防火牆，使溝通更為便利.但由於XML本身的基於標記的特性，很明顯限制了在有超大資料量和有網路瓶頸的應用中的使用.而J2EE的資料訪問規則則顯得略有單薄，但同時卻更簡單，更有效.並且通過對應用程式有效的層次的設計，對於資料庫和基於XML的資料來源的訪問，也是可以無縫的整合的。
安全性:
.NET通過WSA (Web Service Architecture)和WSE (Web Service Extension) 包來提供最新的WEB服務安全保證，JAVA目前還沒有提供這方面的支援。所以在WEB服務安全性上，JAVA明顯比.NET落後一些。
但因為Windows作業系統的安全性沒有unix或者linux高。所以在伺服器的安全上，Java是高於.Net的。
穩定性：
Windows作業系統的複雜性導致.Net做的系統穩定性下降。(不過2008年出來的Windowsserver 2008已經有Core版，但不支援Asp.Net，只有64位的Win2008R2支援，不過現在還是Beta版)。
Linux核心可以定製，所以在這種情況下用Java做的系統穩定性更好一些.
程式設計時的糾錯能力：
VisualStudio中程式碼的即時查錯能力非常弱，很多的要到編譯時才能知道程式碼是否有錯；而在Eclipse中在編寫程式碼的時候對於有錯誤的程式碼和有警告的程式碼（比如一些Private成員沒有被引用）可以立即清晰的提示出來，開發人員可以立即修改有錯誤的程式碼。
開發的效率和複雜度:
C#有容易上手的優勢,而且專案管理,團隊合作相對簡單.開發環境也比較好.
程式碼提示,msdn,等等做得都不錯.網上的doc也多,出了問題解決方案也很多.
java也可以,但其幫助文件沒有msdn好,程式設計環境更是和vs2008沒有辦法相比.
成本：
就BS結構來說，由於.Net開發的週期短，.Net開發的成本大概是用Java的1/3 ~ 1/2.
總結：
就企業而言，內部眾多系統的整合、系統的延展性、安全性是更需要注意的議題，而這些都是J2EE的優勢，也是微軟的不足處。 在效率方面，J2EE陣營主張通過硬體的效能增加來彌補軟體的不足.開放標準，功能強大，易於移植這些都是J2EE的賣點。
技術路線分析
1. 基建工程專案的基本情況
規模，範圍，資料量，效能要求，開發速度上的要求，成本上的要求，對跨平臺的要求，質量上的要求，
2. 常用開發平臺分析及比較
國內外目前最為成熟的兩個B/S系統開發技術路線是J2EE路線和.Net技術路線，下面將就這兩個路線進行一個比較全面的分析和比較。
2.1. J2EE平臺技術路線分析
J2EE是一套全然不同於傳統應用開發的技術架構，包含許多元件，這些元件可簡化並且規範應用系統的開發與部署，進而提高可移植性、安全與再用價值。
J2EE核心是一組技術規範與指南，其中所包含的各類元件、服務架構及技術層次，均有共通的標準及規格，讓各種依循J2EE架構的不同平臺之間，存在良好的相容性，解決過去企業後端使用的資訊產品彼此之間無法相容，導致企業內部或外部難以互通的窘境。
在J2EE架構下，開發人員可依循規範基礎，進而開發企業級應用；而不同J2EE供貨商，同會支援不同J2EE版本內所擬定的標準，以確保不同J2EE平 臺與產品之間的相容性。換言之，基於J2EE架構的應用系統，基本上可部署在不同的應用伺服器之上，無需或者只須要進行少量的程式碼修改，即能大幅提高應用 系統的可移植性(Portability)。
2.1.1. 主要開發框架的分析與比較
目前在業內，主要的基於J2EE實現的整合開發框架有Struts+spring+hibernate和Struts+Ejb+Hibernate。
業務層框架的比較
業務邏輯的構建是整個系統的核心部分。目前業內最為成熟的兩個基於J2EE標準的業務層框架是EJB框架和Spring框架。
這兩個框架都是簡化企業級軟體開發的應用框架，其關鍵是提供一個隱藏了複雜性（例如事務、安全性和永續性）操作的機制。通過選擇這兩種技術中的任何一種，都能夠達到實現完整企業級應有的需求，並簡化開發中的複雜事務。
Ø Spring框架元件是一個流行的，但是非標準的開放原始碼框架元件。它主要是由Interface21Inc.公司開發和控制的。Spring框架元件的架構是基於依賴注入（DI）設計模式的。Spring可以單獨地或者與現有的應用程式伺服器一起工作，它大量地使用XML配置檔案。
Ø EJB 框架元件是一個標準的框架元件，由Java社群組織（JCP）定義，並受到所有主流的J2EE廠商支援。EJB大量使用Java註釋（annotation）。
u 支援力度：
EJB是完全公開的規範標準，它本身是J2EE標準的一部分，因此得到了很多廠商的支援，這樣基於EJB的程式就可以比較輕鬆地在WebSphere、WebLogic以及JBoss之間進行切換。
Spring框架是開源專案，但不是標準的。Spring的介面配置檔案描述都是私有的。所以Spring在其他廠商的支援力度上就不如EJB，使得一旦使用了Spring的特殊服務，那麼就繫結到了 Spring框架上了，要跟換到其他框架將比較困難。
u 靈活性
Spring通過採用鬆散耦合的設計理念，其大量採用XML文件來進行配置，這樣的設計思想在很大程度上增加了它的靈活性，但是同時也增加了開發的複雜度，並造成大量的冗餘。
而EJB框架與應用伺服器結合較緊密，服務被整合封裝，隱藏在EJB介面後面。因為EJB本身就是J2EE標準的一部份，因此，它與其他J2EE服務如JCA，JMX都結合的很好。而缺點也正是結合太緊密，不夠靈活。
u 對WEB層的支援
從對當前主流的WEB開發框架的支援度上來說，由於Spring是一個開源框架，所以其對目前主流的流行框架支援度較好，Spring可以靈活地整合各種 Web框架和模板語言，另外自身也提供了相當強大的Spring-MVC框架。這無疑降低了開發人員在開發過程中的難度。
而EJB在這方面做得就不如Spring，其雖然提供了對JSF的支援，但是目前看來效果並不理想。
u 使用者的使用情況
從目前市場的使用量來看，我們採用2007年11月InfoQ網站做出的一項職位列表（職位列表是技術真正被採納的良好指示器）調查來看，
Java職位列表中對Spring技能的需求已經超越了EJB，也就是說，就業界的普遍使用情況來看，在開發中，已經有越來越多的人和公司支援Spring框架，從上圖的趨勢來看，在今後一段時間裡，將有Spring將獲得更多的支援。
綜合以上幾點，
|
框架 |
EJB2/EJB3 |
Spring Framework |
|
平臺無關性 |
無關 |
無關 |
|
市場使用趨勢 |
減少 |
增加 |
|
靈活性(鬆耦合) |
EJB3比EJB2更具靈活性，EJB3支援應用系統POJO |
支援應用系統POJO，框架本身可分離配置 |
|
功能完整性 |
全面，支援非同步JMS 分散式事務 |
較為全面。有自己的表現層和持久層模板，可支援非同步 |
|
IoC/AOP支援 |
EJB3支援IoC， JBoss等EJB3伺服器支援AOP；基於業務元件的較粗粒度 |
基於JavaBeans類的細粒度支援AOP |
|
Web框架 |
EJB3標準整合JSF，但是JSF並不成熟，和AJAX配合度也不好 |
Spring可以靈活整合各種Web框架和模板語言 |
|
開發人員熟練程度 |
不熟 |
熟練 |
使用EJB 的時候，基於標準的方法、註釋的大量使用、以及與應用程式伺服器的緊密整合形成了強大的廠商無關性和開發者的高效率。使用Spring的時候，一致地使用依賴注入和集中的XML配置檔案，允許開發者構造更加靈活的應用程式，並在同一時刻使用多個應用服務。
表示層和資料層情況
在表示層和資料持久層，目前不二的選擇分別是Struts框架和Hibernate框架。
Struts是一個MVC框架（Framework）,用於開發Java Web應用程式。Struts實現的重點在Controller，包括ActionServlet/RequestProcessor和定製的Action,也為View提供了一系列定製標籤（Custom Tag）。通過Struts實現業務資料、頁面顯示、動作處理分離；管理使用者的請求，做出相應的響應；提供一個流程控制器，委派呼叫業務邏輯和其他上層處理；處理異常；為顯示提供一個資料模型 ；使用者介面的驗證。
Hibernate是一個開放原始碼的物件關係對映框架，它對JDBC進行了非常輕量級的物件封裝，使得Java程式設計師可以隨心所欲的使用物件程式設計思維來操縱資料庫。通過Hibernate將資料表與物件進行關聯，實現資料持久化的重任。
2.1.2. 對資料庫的支援
由於J2EE平臺採用JDBC進行對資料庫的操作，並且常用的資料持久層框架都是基於JDBC進行封裝。
基於這個特性，使得J2EE平臺幾乎支援所有的業界主流的資料庫，包括Oracle、DB2、MySQL、Postgre、SqlServer等。
並且由於JDBC的存在，使得開發人員在進行資料庫操作的時候，可以採用通用的方法進行操作，而不用考慮資料庫的不同所帶來的差異性。
2.1.3. 應有伺服器的選擇
目前支援J2EE的主流企業級應用伺服器有WebSphere和WebLogic。
IBM的WebSphere ApplicationServer 是 一 種功能完善、開放的Web應用程式伺服器，是IBM電子商務計劃的核心部分，它是基於 Java 的應用環境，用於建立、部署和管理 Internet 和 Intranet Web 應用程式。 這一整套產品進行了擴充套件，以適應 Web 應用程式伺服器的需要，範圍從簡單到高階直到企業級。
WebSphere針對以 Web 為中心的開發人員，他們都是在基本 HTTP伺服器和 CGI 程式設計技術上成長起來的。IBM 將提供 WebSphere 產品系列，通過提供綜合資源、可重複使用的元件、功能強大並易於使用的工具、以及支援 HTTP 和 IIOP 通訊的可伸縮執行時環境，來幫助這些使用者從簡單的 Web 應用程式轉移到電子商務世界。
BEA的WebLogic軟體平臺能夠幫助客戶在Web上建立自己的業務或將自己的業務擴充套件到Web上，為客戶提供了一個可靠、可擴充套件、跨平臺的解決方案。作為IBM電子商務應用框架的一個關鍵組成部分，WebLogic軟體平臺為客戶提供了一個使其能夠充分利用Internet的整合解決方案。
WebLogic軟體平臺提供了一整套全面的整合電子商務軟體解決方案。作為一種基於行業標準的平臺，它擁有足夠的靈活性，能夠適應市場的波動和商業目標的變化。它能夠建立、部署、管理、擴充套件出強大、可移植、與眾不同的電子商務應用，所有這些內容在必要時都可以與現有的傳統應用實現整合。以這一穩固的平臺為基礎，客戶可以將不同的IT環境整合在一起，從而能夠最大程度地利用現有的投資。
2.1.4. 硬體平臺及作業系統的選擇
當前大型J2EE系統所部署的伺服器多選擇UNIX伺服器，這也正好和當前業界所存在的大型伺服器廠商所提供的伺服器吻合。如IBM，惠普等，所提供的伺服器都是使用基於UNIX的作業系統，基於UNIX的作業系統也是目前所公認的效能、安全性較高的伺服器作業系統。
同時，當前絕大部分的大型資料庫都支援UNIX、LINUX作業系統，如Oracle, Postgre、DB2。
2.1.5. J2EE方案
綜合分析以上情況，結合專案實際情況，推薦在J2EE技術路線下選用如下方案：
開發框架
採用Struts+Spring+Hibernate的整合開發框架
2.2. .Net平臺技術路線分析
2.1.1. 開發平臺介紹
2.1.2. 對資料庫的支援
2.1.3. 應用伺服器的選擇
2.1.4. 硬體平臺及作業系統的選擇
2.1.5. .NET方案
2.3. J2EE平臺和.Net平臺的綜合比較
總體來說，J2EE平臺是比較成熟的整合解決方案，由超過500家廠商實現了其標準，是各個廠商間協同工作的結果。J2EE平臺是基於Java技術的，這使得它不依賴於執行的硬體平臺和作業系統。J2EE是一種規範，最初由Sun開發，雖然它限制了開發者只能使用單一的程式語言，但今天它已由JavaCommunity Process（JSP）控制，J2EE現在已經是相當開放的平臺。不同的廠商提供了符合規範說明的各種實現方法。
.NET平臺是微軟最新的企業計算環境解決方案。.NET在很多方面和J2EE平臺相似，共享一個概念，與JVM同類，由Common Language Runtime呼叫。它提出了Intermediate Language(IL)，類似於Java Byte –code的概念。但是，.NET可以把不同的語言（包括Java）轉化成IL，而且還提供不只一種語言的支援。
J2EE和.NET平臺的特徵的比較如下：
|
特徵 |
J2EE |
. NET |
|
供應商數量 |
30+ |
微軟（Microsoft） |
|
直譯器 |
JRE |
CLR |
|
動態 Web頁面實現 |
JSP |
ASP.NET |
|
中間層元件 |
EJB |
.NET管理的元件 |
|
資料庫的訪問 |
JDBC |
ADO.NET |
|
支援SOAP，WSDL，UDDI |
是 |
是 |
|
支援分散式應用（如負載均衡等） |
是 |
是 |
|
是否跨平臺 |
是 |
否 |
|
開發效率和複雜度 |
開發效率不如.NET，開發複雜度高。 |
較快。Microsoft Visual Studio .NET整合開發環境，可以幫助開發人員迅速的構建系統。 |
|
資料庫支援 |
對資料庫支援較好。如Oracle、DB2、MySQL、Postgre、SqlServer等一系列的大型資料庫。 |
對資料庫支援較好。如Oracle、DB2、MySQL、Postgre、SqlServer等一系列的大型資料庫。 |
|
和其他系統的整合 |
由於當前電網公司大多數系統都採用J2EE的技術路線，所以可以使得系統能夠較容易的與其他系統進行整合。 |
就電網公司層面來說，與其他系統的整合能力不如J2EE。 |
|
平臺之間的轉換 |
容易。J2EE通過JAVA虛擬機器的支援，可以很容易的實現跨平臺的遷移。 |
不如J2EE |
|
開發人員的支援力度 |
J2EE技術人員較多，能夠得到很好的技術支撐。 |
不如J2EE |
|
硬體平臺及作業系統 |
採用基於UNIX的應用伺服器，伺服器效能較好。 |
必須採用Windows作業系統伺服器，選擇面窄，效能不如UNIX伺服器。 |
|
安全性 |
Windows作業系統的安全性沒有unix或者linux高。所以在伺服器的安全上，Java是高於.Net的 |
.NET通過WSA (Web Service Architecture)和 WSE (Web Service Extension) 包來提供最新的WEB服務安全保證，JAVA目前還沒有提供這方面的支援。所以在WEB服務安全性上，JAVA明顯比.NET落後一些。 |
|
穩定性 |
由於J2EE系統多部署在UNIX伺服器上，應為UNIX核心可以定製，所以在這種情況下用Java做的系統穩定性更好一些 |
不如J2EE |
|
開發成本 |
比.NET高 |
就BS結構來說，由於.Net開發的週期短，.Net開發的成本大概是用Java的1/3 ~ 1/2 |
|
綜合成本 |
由於大量採用開源技術，綜合成本較低。 |
對開源的支援力度不如J2EE，需大量採用商業元件進行支援，增加了專案的綜合成本。 |
3. 系統開發技術路線的選擇
根據以上分析，推薦採用J2EE技術路線，原因主要有一下幾點：
1）與其他系統的整合
雲南電網公司工程專案管理資訊系統涉及到與現有多個系統的整合，包括現有的生產管理系統、物資管理系統、招投標系統、合同系統、辦公OA系統、企業門戶系統。而這些系統都是基於J2EE架構開發的系統。所以，在系統整合方面，J2EE佔有相當的優勢。
2）效能上的考慮
這裡所說的效能包括系統的效率、安全性、穩定性。
雲南電網公司工程專案管理資訊系統所涉及的使用者眾多，資料量龐大，對資料的訪問控制和資料的儲存安全有較高的要求，這就要求有一個高效率、高穩定性、高安全性的部署環境作為支援。高效能的UNIX大型機無疑是最佳選擇，而由於J2EE的JVM的支援，使得采用J2EE技術所構建系統可以很高效的執行於UNIX大型機上。
3）技術上的支援力度
J2EE核心是一組技術規範與指南，其中所包含的各類元件、服務架構及技術層次，均有共通的標準及規格。目前這套標準得到了眾多廠商的支援，包括IBM、SUM等業界大型廠商。在這方面.NET的優勢明顯不如J2EE。
同時，就目前我們的研發力量來說，用於J2EE開發經驗的研發人員也明顯多餘.NET開發人員。所以，如果採用J2EE技術路線，將得到更多的技術上的支援。
4）系統的生存力
J2EE技術所構建的系統，由於JVM（JAVA虛擬機器）的支援，可以使其執行於當前或者今後的各種環境中。
雲南電網公司工程專案管理資訊系統有一個較長的開發週期和很長的生命週期。由於技術的日新月異，為了保證系統在構建過程中和今後的使用過程中不會因為開發技術的更新而落後，不會因為硬體環境的升級換代而無法使用，推薦採用J2EE開發路線。
5）綜合成本
J2EE構建得到眾多開源技術的支援，如開源的報表、開源的流程控制元件等，在很大程度上降低了系統構建的綜合成本。
而.NET對開源的支援力度較低，系統的構建需要購買大量的商業元件，增加了系統的成本。
轉自：http://blog.csdn.net/zhannabiedong/article/details/50800868