淵源：
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