Java不該轉換至.Net的五大理由

2019-11-18 13:29:21

字體：大中小

來源：轉載

供稿：網友

　　.Net Framework號稱是分布式運算產業的下一波重點。
　　
　　由于是全新設計，微軟這項技術在部分領域上顯然有明顯進步，如xml整合、錯誤處理、組件處理，和可重復使用的架構等方面。Web開發的未來十分明確：更快的開發、程序可少寫一些、穩定性會更好。
　　但是假如你目前的應用軟件是用java EJB(EnterPRise JavaBeans)寫出來的呢？將這些軟件移植到微軟新平臺值得嗎？.Net與Java EJB哪一個比較優秀的話題未來一定還有得吵上一陣子，但這類平臺轉移的困難度卻比較輕易猜測。即使你有非常迫切的技術或商業原因必須作轉換，以下還是有五大理由奉勸你不要輕言將Java或J2EE程序轉到.Net平臺上。
　　
　　1. CLR不支持Java
　　轉移至.Net的第一個障礙就是它所支持語言。.Net架構是靠著Common Language Runtime (CLR)來實現多語言的兼容性，但是這個兼容性目前只限于C#、C++、VB和(即將加入的)J# 。而一點也不令人意外的是，Java并非CLR所支持的程序語言。
　　要將Java應用程序轉移至.Net但又無須以CLR支持的語言重新撰寫程序的確是有可能，只需透過Java COM轉換程序或Web services(網絡服務)即可。然而，Java COM卻需依靠第三方軟件才能從Java程序代碼建立COM DLLs。但這方面在爾后的除錯過程會相當困難，同時也增加了環境的復雜度，因此要處理這類異質應用開發必須非常小心，甚至建議不要采用。
　　另一種策略就是將Java程序代碼轉換為C#程序代碼。理論上，你可以利用自動化程序將Java碼直接轉成C# (與J#)語言。例如，ArtinSoft公司的Java Language Conversion Assistant Enterprise Edition (JLCA EE)號稱可將Java轉成C#語言，正確率高達99%，但這樣的產品還沒有經過市場驗證，且經驗法則也會告訴你最好不要信任自動轉碼機制。不管是使用自動轉碼方式還是透過手動，語言轉換總會涉及架構轉變的問題。當你將Java程序改成VB、C++、C#或J# 后，程序中也將會有許多地方必須重新調整(依據應用程序的設置規格而定)。
　　服務器控制太麻煩
　　2. IIS不支持jsp
　　若你認為只要將程序語言從Java改成C#就大功告成，那就錯了，.Net還會要求連同呈現(presentation)語言也要一起轉換，IIS并不支持JSP。從JSP轉換成 asp.net絕對是一項大工程，且你必須完全重寫presentation層不可。另外，許多重要的架構模式在ASP.Net下也不支持，例如透過卷標庫的程序代碼再利用即是一例。卷標庫必須轉換成服務器控制或是服務器端的includes(ssi)。有意思的是，支持卷標庫的Java classes在概念上正好與.Net的程序代碼后置(code-behind)classes相當，但實際轉換還是需要花上許多功夫。
　　
　　
　　3.服務器控制需要重新設計
　　之前提過，在對.Net的程序代碼進行語言轉換時，新的架構需求一定也會跟著浮現。這在計畫.Net服務器控件(server controls)的實作時更是明顯。ASP.Net服務器控件是.Net的最大優勢之一。開發人員可利用預先建立的服務器組件，降低重復性的程序撰寫，且可輕松透過對象存取各項功能。若希望轉換成.Net平臺后也能使用服務器控件的好處，你勢必要移除許多客制化的呈現層、應用程序與數據庫程序代碼，并全部改成服務器控件以及所需的數據庫邏輯。
　　若你是從既有的微軟應用程序作升級，此一程序代碼的抽取(extraction)并不困難，非凡是之前你有良好的程序撰寫習慣的話(分割明朗，條理分明)。然而若是從Java EJB程序作升級時，服務器控件則會動到非常深入的垂直轉換，同時將影響到資料、應用程序、以及程序的呈現層。所有之前儲存的程序、Java對象，和JSP文件都必須轉換成微軟支持的標準，同時還需經過修改才能支持Server Control。
　　例如，DataGrid對象可復雜的表格功能來呈現資料記錄。部分可由使用者自行控制的選項包括行列選擇、頭標樣式以及呼叫(paging)功能等。DataGrid對象比任何客制化或是專屬程序代碼的功能都更強大、維護也更輕易。但若Java應用程序轉換后（假設你要從Oracle資料層轉往SQL Server），要利用此一控制選項的話，你需要：
　　‧將P/L SQL重寫成Transact SQL，并將查詢重新格式化以支持DataGrid。
　　‧將Java程序代碼改成.Net所支持的語言以便取出SQL或預存程序，并支持DataGrid的事件模型。
　　‧移除支持現有客制化的呈現對象，并將JSP模板重寫成ASP.Net。
　　從頭至尾困難重重
　　4.不支持CMP容器治理永續性
　　假設現有的Java程序是由非SQL Server數據庫所支持，那么移植應用程序之后，你還得同時將數據庫轉移至SQL Server上，或者安裝驅動程序好讓.Net應用程序能經由非SQL Server數據庫保持資料持續性。不管哪一種情況，你都必須將JDBC連接類改寫成ADO.Net，并將Java ResultSets移植到ADO.Net DataSets。這項工作本身并不非凡困難，DataSets和ResultSets具有相似的機制，除了實作規格外并不需要動用到架構重建。
　　不過當開發團隊將對象永續(object persistence)從Java轉換到.Net時，問題就會開始出現。.Net并不支持Container Managed Persistence (CMP：容器治理永續性)，也沒有類似的機制。假如你的程序是靠著CMP來保持對象的永續性，你就必須以內嵌式邏輯重寫撰寫對象類別才能進行資料擷取與加載。
　　5.不同的session處理實作
　　EJB標準并不指定session資料的處理，所以EJB session處理實作變成完全與應用服務器有關。由于在不同的session處理實作攸關性能表現、擴充性與網絡設計，因此你必須對應用軟件中的session-handling機制細節有完全的了解。
　　在.Net之中，微軟則采用一種分布式session模型，它通過Microsoft SQL Server存儲應用軟件的狀態，使得session資料同時分配給同一網絡機房中的多個應用軟件服務器。由于.Net依靠SQL Server中的內嵌功能來做session，因此使用Oracle或是其它非SQL服務器數據庫的不同類型應用軟件，都必須建置一個SQL Server instance只為了當作分布式sessions之用。此外，由于大量的session資料將會降低系統總體性能，因此session儲存也必須謹慎使用。
　　
　　
　　轉移難度高成效頂多平手
　　.Net Framework代表著微軟進軍高可用度、企業級應用程序領域的最新成果。以往在IIS、Visual Studio、VB和SQL Server中所缺乏的功能都可在新平臺上找得到。微軟的開發者和用戶現在終于不會矮人一截，不論在擴充性、沿展性、安全與性能上都可與業界對手平起平坐。
　　要害問題是，.Net與EJB解決方案供貨商之間頂多打成平手，沒有任何跡象顯示.Net平臺優于WebSphere、WebLogic、或任何其它EJB應用軟件服務器。對于既有的IIS/ASP解決方案，轉移平臺的效益再也明顯不過。而對于從頭開始的新計畫，.Net也可算是架構平臺的一時之選(端視員工技能與企業偏好)。但是對于既有Java EJB應用軟件而言，一動不如一靜，因為即使你辛勞地轉換了老半天，到頭來發現兩者其實并無差異。
　　
　　
　　Godfrey Baker原著

上一篇：fsck的詳細用法

下一篇：管窺Commons