五個反對向.NET移植Java EJB應用軟件的理由

2019-11-18 13:39:52

字體：大中小

來源：轉載

供稿：網友

　　五個反對向.NET移植java EJB應用軟件的理由

.NET架構已經被吹捧為分布式計算業界的又一個重大的事件。通過重新設計，微軟在xml整合、錯誤處理、部件處理和可重用架構等方面有了顯著的進步。Web開發的前景十分的明確：更快的開發，較少的自定義編碼和穩定性的增強。

但是假如你目前的應用軟件是一個Java EJB應用的話會怎么樣呢？值得付出時間和金錢向微軟的新型平臺進行移植嗎？當.NET通過Java EJB所能獲得的收益這一問題會在未來幾年中繼續被爭論時，這樣的平臺接口中所涉及的難點卻更輕易預料一些。即使有著重要的技術或商業原因在促使這方面的需要，這里還是有五個反對向.NET移植Java或J2EE應用軟件的理由。

1. CLR并不支持Java

向.NET移植的第一個障礙就是它對所支持語言的設置。.NET架構是依靠Common Language Runtime (CLR)來實現多語言的兼容性，但是這個兼容性目前只限于C#, C++, VB和J# 。所以，Java并不被CLR所支持是很正常的。

通過使用Java COM或是Web服務，將Java應用軟件層向.NET移植而不需要用CLR所支持的語言重新編寫應用軟件代碼將會是可能的。然而，Java COM依靠于第三方應用軟件來直接從純Java代碼中創建COM DLLs。調試結果二進制編碼的困難，還有復雜性的增加，都說明了為什么在進行這種應用軟件開發時要謹慎行事，要不然就徹底地避開它。

另一種策略就是將你的Java代碼導向C# 代碼。理論上，你可以通過自動化的應用程序將Java代碼直接翻譯成C# (還有J#)。例如，ArtinSoft的Java Language Conversion Assistant EnterPRise Edition (JLCA EE)承諾了百分之九十九的從Java到C#的自動轉換，但是這樣的產品還沒有在市場上被證實，而且有人爭論要不要相信這種自動代碼轉換。不管是使用自動化的處理方式還是通過人工來進行，這種轉換都毫無疑問地需要有相關的體系架構上的改變。當將一個Java應用程序重新編寫成VB, C++, C# 或J# 時，可能就需要進行大量的再分解工作，這取決于你的應用軟件的具體設定。

2. IIS并不支持jsp

就似乎將一個應用程序的語言端口從Java轉換為C# 還不夠麻煩似的，.NET還需要有一個表示語言端口。而JSP并不被IIS所支持。從JSP轉向 asp.net是意義重大的一件事，它將需要對表示層徹底的重新編寫。還有大型架構模型，例如通過標簽庫的代碼再利用，并不被ASP.NET所支持。標簽庫必須被轉換至服務器控制或是服務器端包含內容(ssi)。有意思的是，支持標簽庫的Java類正好與.NET的代碼之后的類相匹配，但是實際的轉換之中還需要大量的工作。

3.服務器需要重新設計

前面提到了，在對.NET的代碼進行語言的重新編寫時必然需要有新的體系結構。假如.NET服務器控制的執行已經做出計劃，這就會變成非常的明顯。ASP.NET服務器控制是.NET所提供的最大的優勢之一。通過利用預建構的服務器部件，開發者可以減少重復性編碼并輕松地通過對象訪問函數功能。在向.NET移植的過程中利用服務器控制的優勢將可以實現自定義presentation，應用程序和數據庫代碼的去除并取而代之以服務器控制和所要求的數據庫邏輯。

當從一個現有的微軟公司應用軟件進行升級時，這個代碼的解壓縮并不困難，非凡是在由良好的編程習慣帶來的劃分清楚和組織良好的代碼時。然而，當從一個Java EJB應用軟件升級時，服務器控制則要求垂直縱深的移植，且可能同時地影響到應用軟件的數據，應用程序和presentation層。存儲程序，Java對象和JSP文件不僅是需要改為微軟支持標準，他們還需要通過修改來支持Server Control。

例如，DataGrid對象提供了綜合的表格功能來顯示一整套數據記錄。行和列選項，標題風格和分頁功能只是客制化的屬性中的一小部分。DataGrid對象比任何客制化或是私有化代碼都更具有功能性和可維持性。在從Java應用軟件升級時（假設你將一個Oracle數據層移向SQL服務器），要利用這種控制的優勢，你需要：

上一篇：用java實現DB2的自定義函數

下一篇：線程基礎