我國的軟件開發(fā)已經(jīng)逐步從原來的手工作坊式發(fā)展到了軟件工程的階段。同時，軟件開發(fā)本身也在不斷發(fā)展，已從“算法＋數(shù)據(jù)結(jié)構(gòu)＝程序”逐步發(fā)展到了“設(shè)計模式＋對象組件＋開發(fā)工具＝程序”。開發(fā)工具的選擇，已經(jīng)成為軟件開發(fā)成功的要素之一。
開發(fā)工具的選擇主要決定于兩個因素：所開發(fā)系統(tǒng)的最終用戶和開發(fā)人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發(fā)工具的決定性因素；開發(fā)人員的愛好、習(xí)慣、經(jīng)驗也影響著開發(fā)工具的選擇。嚴格的軟件工程管理和開發(fā)人員的技術(shù)水平是軟件開發(fā)成功的關(guān)鍵。
本文介紹一些選擇軟件開發(fā)工具的思路，重點強調(diào)在滿足客戶群體的情況下，軟件工具服務(wù)于軟件工程思想的重要性。
開發(fā)工具 爭顯鋒芒
首先需要強調(diào)的是：開發(fā)工具的比較沒有絕對的標準。評價一種開發(fā)工具，不僅要看它對設(shè)計模式、對象結(jié)構(gòu)以及管理的支撐情況，更重要的是要針對具體的使用環(huán)境、開發(fā)方法、結(jié)構(gòu)體系、開發(fā)群體以及使用群體來評價一種工具的適宜程度。
現(xiàn)有的開發(fā)工具大概分為大而全和小而專兩種類型。Microsoft的Visual Studio系列和IBM的Visual Age系列應(yīng)該屬于前者；其他很多工具，像Delphi/C++Builder/JBuilder/Kylix、PowerBuilder/PowerJ，還有大量的各種SDK等都具有各自的特點，屬于小而專的類型。
大而全的工具一般都提供從前端到后臺，從設(shè)計到編碼測試的完整工具，但在一些特定的功能上，它們不如小而專的工具。
Visual Studio.NET的UML開發(fā)工具(Visual Modeler/Visio)一般只能和Rational Suite中Rational Rose的Logical View相比，它不可能有完整的Rational Unified Process流程；其可視化的Visual Basic沒有辦法和Delphi/C++Builder在速度和功能上相比。
雖然Visual Studio.NET的各個部分都有不足，但其Visio工具能夠更快、更方便地和編程語言整合在一起。Visual Basic在和Office等工具整合時遇到的問題(數(shù)據(jù)類型轉(zhuǎn)化等)比Delphi/C++Builder要少得多。所以，工具類型和具體的情況決定了特定條件下軟件開發(fā)工具最優(yōu)的選擇。
欲善其事 先利其器
開發(fā)工具的選擇主要決定于兩個因素：所開發(fā)系統(tǒng)的最終用戶和開發(fā)人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發(fā)工具的決定性因素；開發(fā)人員的愛好、習(xí)慣、經(jīng)驗也影響著開發(fā)工具的選擇。
最終用戶的需求
程序的最終使用群體是軟件開發(fā)的服務(wù)對象，也影響著開發(fā)工具的選擇。從計算機使用的程度分，最終的使用者可以分為IT人員、各行業(yè)的專業(yè)人員以及普通用戶。使用者的不同，對于軟件的需求就不會相同。IT人員自然需要更多的功能、更自由的定制/二次開發(fā)空間；行業(yè)用戶往往需要一個整體的解決方案，從而提升其整體競爭力；普通用戶顯然要求更方便簡單地使用。用戶的需求分別在自由度、涵蓋度、針對性、方便性等維度展開。
擴展軟件自由度
為了擴展軟件的自由度，較少的封裝和充分的功能暴露是必然的。為了讓用戶自由使用Windows的功能，自由訪問操作系統(tǒng)和硬件資源的語言C++或者Assembler應(yīng)該是最好的選擇。Visual C++成為Microsoft對其操作系統(tǒng)功能的“權(quán)威”封裝，至今在Windows系統(tǒng)級開發(fā)中占據(jù)主流地位；C++ Builder擴充的標準的C++語法，提供了RAD(Rapid Application Development)的支持，但是它的VCL(Visual Component Library)大部分是用Delphi寫的，不像Visual C++的MFC/ATL類庫的純C++源代碼，對于C++程序員的深入編程不利。最近開放源代碼(Open Source)運動風(fēng)靡全球，開放源代碼的C++工具中，GCC受到了普遍的采用。它不僅可以在各種流行操作系統(tǒng)(Windows、Linux、Solaris、HP-Unix)上運行，而且支持Object C、C++的各種擴充語法，甚至可以編譯Java代碼。
涵蓋度各取所求
關(guān)于涵蓋度的要求，不同的系統(tǒng)也是不盡相同的：有的可能要求涵蓋前端、中間件、后臺、數(shù)據(jù)庫，也有可能要求涵蓋各種操作系統(tǒng)和硬件平臺。Visual Studio .NET和IBM的電子商務(wù)平臺都能夠提供從客戶端、中間件到數(shù)據(jù)庫的整體開發(fā)支持。
Visual Studio.NET甚至將可視化帶到了Web客戶端，通過拖放完成Web頁面以后，可以雙點到后臺處理程序的框架代碼中。從軟件工程的思想看來，Visual Studio.NET給程序員提供了強大而且方便的功能，但是并沒有明確的支持需求分析的流程。IBM的Visual Age系列在這個方面做得不錯，Visual Age UML Designer支持從需求分析到設(shè)計、編碼的相對完整過程(不過，在代碼生成方面僅僅對Java和Smalltalk的支持比較好)。
Visual Studio.NET采用COM+作為組件模型，其生成的Web客戶端對于平臺沒有限制。不過，雖然.NET框架應(yīng)該可以移植到非Windows平臺上運行，但是其中間件和服務(wù)端還沒有看到在Unix或者Mac OS上的成功案例。IBM VisualAge+WebSphere+DB2系列大量采用JavaBEAn/J2EE作為組件模型，由于Java的平臺無關(guān)性，客戶端和中間件的跨平臺性就比較好。
當(dāng)然，用小而專的工具組合起來也能完成這些工作，Rational Suite可以完成從業(yè)務(wù)建模、系統(tǒng)建模、模塊建模以及發(fā)布測試的完整過程，Delphi/C++Builder可以利用CORBA或者COM+作為中間件，JBuilder 6更是可以采用Visibroker或者orbix等各種CORBA產(chǎn)品或者WebSphere、iPlanet、BAS、WebLogic等各種J2EE產(chǎn)品。但是，如果不明白Rational中UML和代碼映射的方法以及C++Builder/Delphi/ JBuilder對于代碼的管理方式，要讓建模和編碼配合起來，就需要在Rational Rose中設(shè)置ClassPath以及在Borland工具中設(shè)置源代碼目錄。其中的過程和可能出現(xiàn)的問題都很多，而在Visual Studio.NET中，這些工作僅僅是點幾下鼠標的事情。
也有像Ensemble這樣的公司，專門集成小而專的工具，但是這些軟件的成熟度以及學(xué)習(xí)和掌握也是問題。當(dāng)然，在局部涵蓋性上，Delphi使用CLX的程序可以在Kylix上編譯，從而在Linux上運行；Raining Data Corporation的Omnis Studio 3.1甚至直接支持跨越Windows和Linux平臺的RAD開發(fā)。
針對性各有特色
在針對性上，各個工具都具備各自的優(yōu)勢。在單機應(yīng)用上，Visual FoxPro具有全球最快的數(shù)據(jù)訪問引擎。而PowerBuilder在開發(fā)兩層數(shù)據(jù)庫應(yīng)用上，特別是用數(shù)據(jù)窗口和Sybase數(shù)據(jù)庫后臺掛接，用PowerDesign建模，不僅開發(fā)速度快，而且效率和穩(wěn)定性也比較好。在三層應(yīng)用上，使用Visual Basic/C++/C#+ADO，如果再使用SQL Server，就在性能、開發(fā)效率、穩(wěn)定性上都有保證；而使用C++Builder/Delphi+DataSnap(MIDAS)，在掛接非微軟數(shù)據(jù)庫，或者需要和CORBA程序交互時都具有優(yōu)勢。
對于多層分布式應(yīng)用，COM+規(guī)范和CORBA產(chǎn)品(orbix, visibroker等)往往決定了開發(fā)工具的選擇。COM+的開發(fā)工具一般采用Visual Studio.NET或Borland的產(chǎn)品，而由于CORBA的編程語言和系統(tǒng)平臺的無關(guān)性，各種開發(fā)平臺一般都可以。另外，針對C/C++編程，DSET公司的DSG在高端應(yīng)用(一般在電信領(lǐng)域)中，它在與網(wǎng)絡(luò)協(xié)議棧的無關(guān)性、同/異步消息處理、海量通信能力、嵌入式到大型機的移植性等方面,具有獨特的優(yōu)勢。在服務(wù)器端開發(fā)上，COM+、CORBA 3.0、J2EE都支持組件模型，分別利用MSMQ、CORBA Messaging System、JMS完成異步通信。COM+仍然主要集中在Windows平臺上，CORBA 3.0的Java語言部分包含整個J2EE規(guī)范。但是，CORBA作為一個跨語言跨平臺的規(guī)范，現(xiàn)在支持3.0版本非Java語言的產(chǎn)品還不多，支持其核心——CCM(CORBA Component Model)的C++編程的產(chǎn)品有iCMG公司K2-CCM等。
J2EE的組件(EJB)已經(jīng)發(fā)展到了1.2版本。滿足該規(guī)范的產(chǎn)品——BEA WebLogic、Borland BAS、 IBM WebSphere、Oracle 9i甚至免費的JBOSS都得到了廣泛的應(yīng)用。BEA WebLogic 7.0在前端開發(fā)工具上做了大量的工作，聲稱將J2EE開發(fā)和Visual Basic放在同一個級別上(其內(nèi)部名字就是Visual Basic for Java)。
微軟方便性最好
在方便性上，由于有大量用戶的實踐，微軟的開發(fā)工具應(yīng)該是最好的。它在可視化、工具間互操作性、穩(wěn)定性、文檔的豐富性上都具有明顯的優(yōu)勢。Borland Delphi/C++Builder在可視化上和Visual Basic/C#基本上類似，但是他們在穩(wěn)定性上不足(C++Builder 5.0自動生成的CORBA程序的debug版會報錯(Exception))；IBM Visual Age系列的穩(wěn)定性不錯，但是它們的可視化編程不是非常方便；在文檔方面，更是沒有一種工具具有Visual Studio自帶的MSDN那樣的容量(兩張光盤)。
開發(fā)者的偏愛
開發(fā)工具是給開發(fā)者用的，開發(fā)人員是這些工具的用戶。不同的開發(fā)人員對工具的偏愛也不同。Pascal程序員一般都會鐘愛Delphi/Kylix；Windows的C++程序員則會選擇C++Builder或者Visual C++；在不同平臺下C++編程的人員可能會更加喜歡GCC；Smalltalk程序員恐怕就只會考慮Visual Age Smalltalk；而Turbo Lisp、Visual Fortran、Perl Builder等開發(fā)工具在其他各種編程語言的程序員中也被大量采用。
現(xiàn)在，各種編程語言的功能互相融合，像Borland Delphi和C++Builder之間的功能差異，在語言上表現(xiàn)得已經(jīng)非常少了。除了編程語言的偏愛以外，不同操作系統(tǒng)的程序員使用的工具也不同：Solaris系統(tǒng)下的程序員更多地使用CC編寫C++/C的后臺程序，用Perl編寫框架或者測試腳本，用TCL/TK編寫界面程序；雖然Windows下也有這些工具，但是更多程序員恐怕還是會選擇支持RAD的工具?，F(xiàn)在，人們普遍認可一種趨勢：操作系統(tǒng)、編程語言在開發(fā)上的差異正在迅速消失。XML有效地解決了在不同系統(tǒng)下統(tǒng)一數(shù)據(jù)表達的問題；通過虛擬機，Java程序能夠在不同操作系統(tǒng)下執(zhí)行；微軟的.NET框架能夠利用C++/Basic/C#來編程。
平臺和語言間的交互使得各種工具對于通用標準的支持越來越重視。Sun新推出的Java的XML開發(fā)包，明確支持由微軟和IBM提出的SOAP規(guī)范，Visual Studio.NET也明確支持Java語言(J#)。雖然現(xiàn)在還僅僅是一個開端，但是，語言和平臺的融合是一種不可阻擋的趨勢：必然有更多的編譯器將其他語言編譯成為Java字節(jié)碼，Visual Studio.NET也必然會將程序編譯到其他操作系統(tǒng)中。
然而，伴隨著技術(shù)的融合，差異性也將永遠存在。微軟為了互聯(lián)網(wǎng)應(yīng)用而推出.NET框架，Windows和Visual Studio都做了巨大的改進。為了這個框架，Visual Studio.NET甚至推出了一個新的編程語言C#，它具有Java語言的大部分特征，同時在固定內(nèi)存區(qū)允許使用指針。C#在設(shè)計上確實非常先進，但是由于缺乏大量的使用，而且缺乏Java 2中的安全特性，是否能夠吸引大量的程序員，還是一個未知數(shù)；同時，C#中的很多特性(像對象方法的修飾詞等)都是微軟COM+規(guī)范在編程語言中的映射，這會在今后的操作系統(tǒng)平臺移植時產(chǎn)生麻煩。
除了開發(fā)人員的平臺特性和語言偏愛以外，人員間的配合模式也決定著工具的選擇。自由軟件普遍采用的跨地域開發(fā)模式，對于使用CVS版本管理系統(tǒng)的開發(fā)工具非常合適。而由于Visual Studio.NET在開發(fā)調(diào)試中會改變本地Windows注冊庫，跨地域開發(fā)就非常不方便。
當(dāng)然，不能排除別的因素對于開發(fā)工具的影響。舉例來說，行業(yè)的特點以及遺留系統(tǒng)(legacy system)對于開發(fā)的影響也是不可忽略的：電信行業(yè)的軟件開發(fā)，由于有ITU-T規(guī)范的存在，Java要代替現(xiàn)有的C/C＋＋開發(fā)模式還不能像通用軟件那么快。但是，歸結(jié)起來，軟件的開發(fā)總是一個由人完成和為人服務(wù)的。無論其他因素的影響力現(xiàn)在有多大，今后的發(fā)展也必然是由人來決定的。
開發(fā)利器1 PB集成 降本提效
互聯(lián)網(wǎng)已經(jīng)從前幾年的“接入為王”、“內(nèi)容為王”，發(fā)展到了今天的“應(yīng)用為王”的時代了。大批的應(yīng)用軟件開發(fā)人員也將進入Web應(yīng)用開發(fā)領(lǐng)域。他們熟悉應(yīng)用業(yè)務(wù)領(lǐng)域、熟悉傳統(tǒng)C/S的開發(fā)技巧，但不一定熟悉HTML/javascript, 也不一定熟悉3-tier體系架構(gòu)。這對平臺和工具廠商來說是一個巨大的商機。
PB異軍突起
現(xiàn)在究竟是什么阻礙了Web應(yīng)用和3-tier的大批出現(xiàn)呢？仍然是工具。一個好的開發(fā)工具應(yīng)該是在日常開發(fā)中能夠屏蔽煩瑣的技術(shù)細節(jié)，并允許高級開發(fā)人員直接干預(yù)這些技術(shù)細節(jié)。在3-tier開發(fā)中，我們會同時面對數(shù)據(jù)庫操作(表、數(shù)據(jù)維護、存儲過程和觸發(fā)器的維護等)，Component編寫和調(diào)試, 網(wǎng)頁(尤其是調(diào)用這些Component的動態(tài)頁面)的編寫和調(diào)試，以及一些2-tier應(yīng)用程序的維護等許多任務(wù)。
一般說來，完成這些任務(wù)需要使用多種工具，在開發(fā)時需要在多個工具之間切換，由此造成了開發(fā)效率的低下和開發(fā)難度的提高。而PB8/PJ4很好地解決了這些問題。所有這些任務(wù)，都可以在同一個開發(fā)環(huán)境中完成，開發(fā)人員能非?？焖俚鼐帉懟跀?shù)據(jù)庫的業(yè)務(wù)邏輯Component以及調(diào)用這些Component的Web-Client或PB-Client。尤其是Sybase把2-tier中的王牌Datawindow擴展到了HTML領(lǐng)域，使得數(shù)據(jù)庫驅(qū)動的動態(tài)頁面實現(xiàn)起來非常容易。
總體來說，Sybase的優(yōu)勢在于具備開發(fā)企業(yè)信息系統(tǒng)所需的全系列的工具，包括系統(tǒng)分析和系統(tǒng)設(shè)計工具PowerDesigner、應(yīng)用開發(fā)工具PowerBuilder和PowerJ、應(yīng)用服務(wù)器EAServer(內(nèi)含Jaguar和PowerDynamo)、數(shù)據(jù)庫Adaptive Server Enterprise(以及復(fù)制服務(wù)器等)。這些工具由于是同一家公司的產(chǎn)品，具有非常好的互操作性。同時，這些工具對標準的支持非常好，比如EAServer對組件模型就同時支持COM、CORBA和J2EE，可以用C/C++和JAVA來編寫各種Component, 甚至以CORBA的形式支持用PowerBuilder直接編寫Component。
反面意見
許多人都提到PB的許多不足，比如與VB和Delphi相比界面較單調(diào)、對于Windows API的調(diào)用能力較差(PB本身不直接支持指針)等等。然而，在某些特定場合，這些問題會變成優(yōu)勢。企業(yè)應(yīng)用的核心在于數(shù)據(jù)訪問和業(yè)務(wù)邏輯。界面的花哨倒并不重要。在企業(yè)應(yīng)用中，好的用戶界面設(shè)計是指符合用戶業(yè)務(wù)思維方式和業(yè)務(wù)流程的界面設(shè)計，而不是花哨的界面設(shè)計。而不支持指針，則會大大提高程序的可靠性。這些問題，實際上都源自PB產(chǎn)品的定位：不是作為一個通用開發(fā)工具，而是作為一個專用的企業(yè)信息系統(tǒng)開發(fā)工具。在這個領(lǐng)域，PB/PoerJ確實是無可匹敵的。
在系統(tǒng)分析和設(shè)計工具領(lǐng)域，Rational Rose是一個常被人稱道的工具。然而在現(xiàn)實的信息系統(tǒng)項目和應(yīng)用軟件開發(fā)中，我們面對的不是純面向?qū)ο蟮沫h(huán)境，而是關(guān)系數(shù)據(jù)庫和面向?qū)ο蟮幕旌檄h(huán)境。并且，用戶無一例外地希望數(shù)據(jù)庫的訪問有盡可能高的性能。
第三方工具
在互聯(lián)網(wǎng)上您可以找到大量第三方的工具來幫助您提高您在開發(fā)PowerBuilder應(yīng)用時的效率和質(zhì)量。下面就是兩個例子：
大家一定會了解Visual C/C++與MFC的關(guān)系。在C/S環(huán)境中，PowerBuilder也有一個PFC與之對應(yīng)。當(dāng)然，兩者的層次是不同的。MFC提供了底層的封裝，而PFC提供了數(shù)據(jù)庫應(yīng)用的更高層面的封裝。對PFC的深入應(yīng)用可以大大提高系統(tǒng)的開發(fā)效率和開發(fā)質(zhì)量。進入到3-tier的世界，如果用PB來開發(fā)Component，同樣也有一些很好的類庫，比較著名的就是EAF。對這些類庫的深入應(yīng)用并形成自己的類庫，是迅速提高產(chǎn)品和項目的質(zhì)量和效率捷徑。
確保應(yīng)用軟件的質(zhì)量一定是許多人都很頭疼的問題。那我們就先來看看最基本的問題吧。在單元測試這個領(lǐng)域，大家一定了解在Java中的JUnit這個單元測試工具。PB中也有一個對應(yīng)的工具叫做PBUnit。你可以在開發(fā)過程中，在PBUnit環(huán)境中編寫測試腳本，反復(fù)對你的Object進行回歸測試，并自動記錄、分析測試結(jié)果。對于常常是包含了大量數(shù)據(jù)處理的PB應(yīng)用程序來說，這是非常有價值的。(祝楓)
開發(fā)利器2 WebSphere Studio 開放開發(fā)
IBM正在交付一個基于WebSphere Studio Workbench技術(shù)的電子商務(wù)應(yīng)用程序開發(fā)工具的新套件。WebSphere Studio Workbench是一個用于工具開發(fā)和集成的平臺。這是 IBM 對開放源碼Eclipse Project的增值實現(xiàn)。WebSphere Studio Workbench提供用于開發(fā)源代碼編輯器和其它用戶界面的一組API、模型和框架，以及對資源管理的公共服務(wù)、調(diào)試和團隊編程的訪問。該平臺實現(xiàn)了現(xiàn)有標準并提供用于將功能部件和函數(shù)作為插件添加的擴展點。IBM 和獨立軟件供應(yīng)商(ISV)正在開發(fā)插入這個框架的工具。
WebSphere Studio Site Developer和WebSphere Studio Application Developer是IBM合并和擴展WebSphere Studio Workbench而成的兩個產(chǎn)品。這些產(chǎn)品是計劃中將要跨越所有電子商務(wù)開發(fā)角色的集成開發(fā)工具套件的一部分，從Web開發(fā)者到Java開發(fā)者、到商務(wù)分析師、到設(shè)計師、到企業(yè)程序員。WebSphere Studio開發(fā)工具系列將添加更多產(chǎn)品。
客戶希望有開放標準、工具集成、更大的靈活性和結(jié)合到現(xiàn)有應(yīng)用程序的能力。這些還只是WebSphere Studio產(chǎn)品套件所交付的部分優(yōu)點。
垂直和水平集成
傳統(tǒng)上，軟件供應(yīng)商提供垂直工具，迫使客戶自己做集成。WebSphere Studio Workbench的目的是提供一個 IBM 和 ISV 都能容易地擴展的平臺。供應(yīng)商已經(jīng)擁有了該技術(shù)并在此基礎(chǔ)上積極地構(gòu)建工具。
在Workbench上構(gòu)建的每個WebSphere Studio產(chǎn)品都將提供已集成的工具，使您可以專注于構(gòu)建應(yīng)用程序而不必費力去集成工具。
開放標準
WebSphere Studio套件中的所有產(chǎn)品都是構(gòu)建在開放標準上的，并且它們所生成的代碼也是與開放標準一致的。可以構(gòu)建和部署滿足Servlets 2.2、JavaServer Pages(JSP)1.1和 Enterprise JavaBEAns(EJB)1.1規(guī)范的最新型的(state-of-the-art)服務(wù)器端應(yīng)用程序(在Site Developer產(chǎn)品中將不包含EJB開發(fā)工具。)所有構(gòu)建在WebSphere Studio Workbench上的產(chǎn)品，都包含CVS(Concurrent Versions System)。
基于角色的開發(fā)
WebSphere Studio產(chǎn)品系列中的每個成員都是為特殊電子商務(wù)開發(fā)角色或某種角色范圍設(shè)計的。例如，Site Developer是為開發(fā)和管理整個網(wǎng)站的Web開發(fā)者設(shè)計的。Application Developer包含Site Developer的所有功能并添加了對在業(yè)務(wù)邏輯方面(包含 EJB)工作的程序員的支持。當(dāng)IBM交付WebSphere Studio系列的未來成員時，它將擴展其選項范圍，將產(chǎn)品與用戶的角色和需求相匹配。
在每個WebSphere Studio解決方案內(nèi)部，面向任務(wù)的視圖篩選出復(fù)雜性并只提供與手邊的任務(wù)相關(guān)的功能。用戶根據(jù)此時正在開發(fā)或分析什么，或者根據(jù)他們在項目中的角色切換視圖。因為不同的開發(fā)者以不同的方法工作，所以視圖可以定制。因為他們使用WebSphere Studio Workbench技術(shù)構(gòu)建，所以所有工具和視圖共享一個公共外觀，這減小了學(xué)習(xí)難度并使得用戶的生產(chǎn)力最大化。并且，因為項目的開發(fā)資源存儲在單個資源庫中，所以您獲得了對項目的最大共享性和一致團隊支持。
最大編程性能
除了將應(yīng)用程序開發(fā)者們從工具集成任務(wù)中解放出來以外，Site Developer和Application Developer 都以許多方法優(yōu)化了程序員的生產(chǎn)力。(蘇永)
開發(fā)利器3 微軟.NET和C#
微軟現(xiàn)在把自己的希望寄托在新的.NET應(yīng)用程序框架之上。雖然在.NET中幾乎可以使用任何一種編程語言，但是開發(fā)者更熱衷的還是微軟的C#和C++。因為它們改變了幾乎所有從桌面軟件到具有Web功能的企業(yè)解決方案的Windows開發(fā)規(guī)則,所以這些技術(shù)的潛力非常巨大。
.NET框架和C#擴展了Windows的功能，C#和Visual Studio .NET的結(jié)合使得創(chuàng)建和配置Web服務(wù)幾乎可以自動進行。并且，和傳統(tǒng)的ASP應(yīng)用程序相比，ASP.NET應(yīng)用程在性能、穩(wěn)定性以及可擴展性方面都有了實質(zhì)性的提高。
雖然有很多優(yōu)點，但是.NET價格不菲。目前的Windows開發(fā)者如果要轉(zhuǎn)向.NET框架，都必須進行再培訓(xùn)，并且所需費用很高。由于.NET框架中有很多重大的改變以及復(fù)雜度的提高，因而現(xiàn)在的VB程序員將無法應(yīng)對這些變化。C++程序員則會因為C#繼承了自己熟悉語言中的基本內(nèi)容而感到高興，但是他們也會發(fā)現(xiàn)在API以及語言方面C#還是有很大的改變。
在ASP.NET中，由于不再使用VBScript，而只用JScript，并且在系統(tǒng)服務(wù)中也不再提倡使用COM(Component Object Model)，因此要把現(xiàn)有的Web應(yīng)用程序轉(zhuǎn)換成ASP.NET，重新編寫程序代碼要耗費大量的時間和精力。如果要把現(xiàn)有Java項目轉(zhuǎn)入到.NET框架中，即使你使用的是J#(微軟的Java開發(fā)語言)，那么要完成一個項目的遷移，至少也要花費幾個月的時間。如果要把服務(wù)器從Unix平臺遷移到Windows,那么更是要求所有的
IT職員都必須掌握一門新的技術(shù)。
考慮到以上因素，我們就很容易理解為什么.NET和C#會讓人們既關(guān)注又擔(dān)憂。當(dāng)然，對于已經(jīng)在從事Windows平臺下開發(fā)的公司和企業(yè)來說，不是接不接受.NET的問題，而是什么時候接受的問題。目前普遍的觀點認為，如果不及時實現(xiàn)向.NET的遷移，那么將最終不堪忍受來自開發(fā)者、商業(yè)伙伴、應(yīng)用程序提供商以及工具提供商的壓力。
當(dāng)然，相對于來自Java、Unix和Linux擁護者的挑戰(zhàn)來說，微軟要把Windows下的開發(fā)者吸引到.NET框架上來。在和Java和J2EE的競爭中，微軟主要有兩張牌可打，即Visual Studio .NET和Web服務(wù)。測試版的Visual Studio .NET IDE(整合開發(fā)環(huán)境)已經(jīng)在開發(fā)人員中引起了不小的震動。相信在Web服務(wù)領(lǐng)域和Java競爭時，它將成為微軟的一把利器。(伊利貴)
開發(fā)利器4 鐘情Delphi 6
Delphi 6 是當(dāng)前 Windows 平臺上全面支持最新 Web 服務(wù)的快速開發(fā)工具。無論是企業(yè)級用戶還是個人開發(fā)者，都能夠利用Delphi 6 輕松、快捷地構(gòu)建新一代電子商務(wù)應(yīng)用。Delphi 6優(yōu)秀在何處？
高效的開發(fā)
Delphi 6是一個RAD(Rapid Application Development 快速開發(fā)工具)。它有可視化的開發(fā)環(huán)境，當(dāng)然具有類似功能的開發(fā)工具也不少(如Visual Basic)，但Delphi 6有如下的獨到之處：
Delphi 6是真正面向?qū)ο蟮摹Ｆ錁?gòu)建的VCL庫中的所有組件都可以被繼承以創(chuàng)建新的組件，包括窗體類TForm。相比之下，ActiveX組件缺乏這種靈活性。
Delphi 6的CodeInsight技術(shù)(即代碼自動完成功能)是建立在編譯器信息上的，而VB使用的是類型庫信息，使用編譯器信息的好處是更具靈活性。不過，時常有程序員抱怨Delphi 6的代碼提示時間太長。
高效的編譯
可以說，Delphi 6是Windows平臺上最快的高級語言本地代碼編譯器了。編譯速度快有什么好處呢？快速的編譯器可以讓你頻繁地在修改代碼和編譯運行的狀態(tài)間切換。至少，我自己已經(jīng)非常習(xí)慣了這樣的工作方式：運行程序看一下效果，退出程序修改少量代碼再運行程序。而Delphi 6的編譯器從來不會讓我有等待的感覺。
高效的執(zhí)行
Delphi 6與C++Builder使用的是同一個后端優(yōu)化器，因此其生成代碼的效率與優(yōu)秀的C++編譯器生成代碼效率相同。
Delphi 6生成完全本地代碼，因此Delphi 6編譯結(jié)果的可執(zhí)行文件可以被獨立執(zhí)行、分發(fā)(對于“綠色軟件”的開發(fā)，這一點十分重要)。不需要其他運行庫支持。當(dāng)然，你也可以選擇動態(tài)鏈接編譯，這樣可以大大減小可執(zhí)行文件的長度，不過這種情況下在分發(fā)程序時，必須同時分發(fā)必要的運行庫文件。
構(gòu)建Windows/Linux 應(yīng)用
Delphi 6 與Kylix兼容。使用Kylix，可在Linux平臺上重新編譯基于Windows平臺的CLX應(yīng)用；而利用Delphi 6，即可在Windows上重新編譯基于CLX組件的Linux應(yīng)用。Delphi 6包含BaseCLX、VisualCLX、DataCLX和NetCLX四個組件。
與AppServer集成
Delphi 6通過最新SIDL與AppServer連接。它為AppServer應(yīng)用開發(fā)出高性能、具有豐富GUI環(huán)境的客戶端應(yīng)用，通過Internet將AppServer的EJB功能作為遵循業(yè)界標準的SOAP/XML Web服務(wù)發(fā)布到全球。(李爭)
編后語
現(xiàn)在，各種開發(fā)工具的功能相互大量重復(fù)，一個大而全的工具幾乎總是可以被幾個別的工具代替。工具的選擇確實非常讓人迷惑，但是，無論是開發(fā)人員還是管理人員都應(yīng)該意識到：工具只能起到協(xié)助的作用，嚴格的軟件工程管理和開發(fā)人員的技術(shù)水平才是軟件開發(fā)成功的關(guān)鍵。成功開發(fā)加上有效的管理和市場運作，才能構(gòu)成一個完整的成功軟件。
開發(fā)工具的對壘
軟件開發(fā)人員沒有人會不知道微軟的.NET和Sun的J2EE。二者盡管所提供的方法不同，但都具有許多非常優(yōu)秀的特點。
二者的可移植性都非常好。.NET的核心只能工作在Windows環(huán)境下，但從理論上講可以支持多種語言開發(fā)?只要這些語言的子集已經(jīng)定義好，并為他們建立了IL編譯器?。對于J2EE來說，只要遵循Java VM?規(guī)則?和一組平臺需要的服務(wù)，就可以在任何平臺上工作。因為所有定義J2EE平臺的規(guī)范，都已經(jīng)向公眾公布，所以，許多供應(yīng)商也提供兼容產(chǎn)品和開發(fā)環(huán)境。
.NET并不是一種精巧的標志，而是微軟策略的重大轉(zhuǎn)移，它將給其操作系統(tǒng)平臺帶來更大的支持率?，F(xiàn)在他們正努力把Java和開放資源自身所特有的語言逐步開放，然后實現(xiàn)直接滿足開發(fā)商的需要。Java清除了平臺的障礙。但是為了用J2EE來做開發(fā)工作，用戶必須在Java環(huán)境下工作。而.Net是想讓用戶使用自己選擇的語言來建造.NET應(yīng)用程序，這是十分美妙的。
對于微軟的開發(fā)商，.NET是一個好的構(gòu)架，用戶可以將許多事情交給微軟的體系結(jié)構(gòu)去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，C＃比C和C＋＋更好。所以，如果現(xiàn)在正在微軟的開發(fā)構(gòu)架中從事開發(fā)工作，將.NET的元件采納到你的體系結(jié)構(gòu)中，顯然是一個明智的選擇。不過，雖然.NET平臺描繪了美好的藍圖，但其設(shè)想要全部成為現(xiàn)實，還有較長的路要走。例如IL公共語言的運行，目前還有某些明顯的障礙需要克服。想要把每一種語言和元件運行時集成起來，必須定義這種語言的子集/超集，并清晰地影射到IL上；此外必須定義結(jié)構(gòu)，以便提供IL需要的元數(shù)據(jù)；還有必須要開發(fā)適用于兩種編譯語言結(jié)構(gòu)的編譯器，集成到IL部件字節(jié)代碼中；同時還要生成對現(xiàn)有IL元件的語言專用接口。
由于歷史的原因，在Java語言中使用非Java語言，必須要開發(fā)非Java語言到JavaVM的眾多轉(zhuǎn)換器。因此，在Java環(huán)境中寫代碼，就必須要承受將額外的翻譯工作加到目標構(gòu)架上。如果Java環(huán)境是目標，人們通常會選擇學(xué)習(xí)Java。而如果目標環(huán)境是.NET，那么人們將會選擇學(xué)習(xí)C＃。(伊利貴)
64位的軟件開發(fā)
因為在內(nèi)存容量、I/O處理效率等方面64位系統(tǒng)有著32位系統(tǒng)無可比擬的優(yōu)勢，因此在高端應(yīng)用上，Sun、IBM和HP等大腕一直熱衷于64位系統(tǒng)?？梢灶A(yù)見，在不久的將來，Intel的64位處理器將成為Sparc的主要競爭對手。
不過，由于Linux和Windows環(huán)境下的主要的應(yīng)用程序都是32位的，因此，軟件廠商和自由軟件項目必須為64位系統(tǒng)重寫他們的應(yīng)用程序。所幸的是，由于Java的盛行以及.NET的出現(xiàn)，這將使得應(yīng)用程序向Itanium的移植變得非常神速。IBM已經(jīng)推出了其用于Itanium的Java SDK(軟件開發(fā)工具包)，此外，微軟的.NET框架在其發(fā)行.NET Server時，也將登陸Itanium。而Borland更是已經(jīng)使其Java開發(fā)工具和服務(wù)器可以在Itanium上運行。
注:本文轉(zhuǎn)自http://sd.csdn.net/n/20060529/91048.html
