五個(gè)反對(duì)向.NET移植Java EJB應(yīng)用軟件的理由

2019-11-18 13:39:52

字體：大中小

供稿：網(wǎng)友

　　五個(gè)反對(duì)向.NET移植java EJB應(yīng)用軟件的理由

.NET架構(gòu)已經(jīng)被吹捧為分布式計(jì)算業(yè)界的又一個(gè)重大的事件。通過(guò)重新設(shè)計(jì)，微軟在xml整合、錯(cuò)誤處理、部件處理和可重用架構(gòu)等方面有了顯著的進(jìn)步。Web開(kāi)發(fā)的前景十分的明確：更快的開(kāi)發(fā)，較少的自定義編碼和穩(wěn)定性的增強(qiáng)。

但是假如你目前的應(yīng)用軟件是一個(gè)Java EJB應(yīng)用的話會(huì)怎么樣呢？值得付出時(shí)間和金錢(qián)向微軟的新型平臺(tái)進(jìn)行移植嗎？當(dāng).NET通過(guò)Java EJB所能獲得的收益這一問(wèn)題會(huì)在未來(lái)幾年中繼續(xù)被爭(zhēng)論時(shí)，這樣的平臺(tái)接口中所涉及的難點(diǎn)卻更輕易預(yù)料一些。即使有著重要的技術(shù)或商業(yè)原因在促使這方面的需要，這里還是有五個(gè)反對(duì)向.NET移植Java或J2EE應(yīng)用軟件的理由。

1. CLR并不支持Java

向.NET移植的第一個(gè)障礙就是它對(duì)所支持語(yǔ)言的設(shè)置。.NET架構(gòu)是依靠Common Language Runtime (CLR)來(lái)實(shí)現(xiàn)多語(yǔ)言的兼容性，但是這個(gè)兼容性目前只限于C#, C++, VB和J# 。所以，Java并不被CLR所支持是很正常的。

通過(guò)使用Java COM或是Web服務(wù)，將Java應(yīng)用軟件層向.NET移植而不需要用CLR所支持的語(yǔ)言重新編寫(xiě)應(yīng)用軟件代碼將會(huì)是可能的。然而，Java COM依靠于第三方應(yīng)用軟件來(lái)直接從純Java代碼中創(chuàng)建COM DLLs。調(diào)試結(jié)果二進(jìn)制編碼的困難，還有復(fù)雜性的增加，都說(shuō)明了為什么在進(jìn)行這種應(yīng)用軟件開(kāi)發(fā)時(shí)要謹(jǐn)慎行事，要不然就徹底地避開(kāi)它。

另一種策略就是將你的Java代碼導(dǎo)向C# 代碼。理論上，你可以通過(guò)自動(dòng)化的應(yīng)用程序?qū)ava代碼直接翻譯成C# (還有J#)。例如，ArtinSoft的Java Language Conversion Assistant EnterPRise Edition (JLCA EE)承諾了百分之九十九的從Java到C#的自動(dòng)轉(zhuǎn)換，但是這樣的產(chǎn)品還沒(méi)有在市場(chǎng)上被證實(shí)，而且有人爭(zhēng)論要不要相信這種自動(dòng)代碼轉(zhuǎn)換。不管是使用自動(dòng)化的處理方式還是通過(guò)人工來(lái)進(jìn)行，這種轉(zhuǎn)換都毫無(wú)疑問(wèn)地需要有相關(guān)的體系架構(gòu)上的改變。當(dāng)將一個(gè)Java應(yīng)用程序重新編寫(xiě)成VB, C++, C# 或J# 時(shí)，可能就需要進(jìn)行大量的再分解工作，這取決于你的應(yīng)用軟件的具體設(shè)定。

2. IIS并不支持jsp

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

3.服務(wù)器需要重新設(shè)計(jì)

前面提到了，在對(duì).NET的代碼進(jìn)行語(yǔ)言的重新編寫(xiě)時(shí)必然需要有新的體系結(jié)構(gòu)。假如.NET服務(wù)器控制的執(zhí)行已經(jīng)做出計(jì)劃，這就會(huì)變成非常的明顯。ASP.NET服務(wù)器控制是.NET所提供的最大的優(yōu)勢(shì)之一。通過(guò)利用預(yù)建構(gòu)的服務(wù)器部件，開(kāi)發(fā)者可以減少重復(fù)性編碼并輕松地通過(guò)對(duì)象訪問(wèn)函數(shù)功能。在向.NET移植的過(guò)程中利用服務(wù)器控制的優(yōu)勢(shì)將可以實(shí)現(xiàn)自定義presentation，應(yīng)用程序和數(shù)據(jù)庫(kù)代碼的去除并取而代之以服務(wù)器控制和所要求的數(shù)據(jù)庫(kù)邏輯。

當(dāng)從一個(gè)現(xiàn)有的微軟公司應(yīng)用軟件進(jìn)行升級(jí)時(shí)，這個(gè)代碼的解壓縮并不困難，非凡是在由良好的編程習(xí)慣帶來(lái)的劃分清楚和組織良好的代碼時(shí)。然而，當(dāng)從一個(gè)Java EJB應(yīng)用軟件升級(jí)時(shí)，服務(wù)器控制則要求垂直縱深的移植，且可能同時(shí)地影響到應(yīng)用軟件的數(shù)據(jù)，應(yīng)用程序和presentation層。存儲(chǔ)程序，Java對(duì)象和JSP文件不僅是需要改為微軟支持標(biāo)準(zhǔn)，他們還需要通過(guò)修改來(lái)支持Server Control。

例如，DataGrid對(duì)象提供了綜合的表格功能來(lái)顯示一整套數(shù)據(jù)記錄。行和列選項(xiàng)，標(biāo)題風(fēng)格和分頁(yè)功能只是客制化的屬性中的一小部分。DataGrid對(duì)象比任何客制化或是私有化代碼都更具有功能性和可維持性。在從Java應(yīng)用軟件升級(jí)時(shí)（假設(shè)你將一個(gè)Oracle數(shù)據(jù)層移向SQL服務(wù)器），要利用這種控制的優(yōu)勢(shì)，你需要：

上一篇：用java實(shí)現(xiàn)DB2的自定義函數(shù)

下一篇：線程基礎(chǔ)