項目存檔管理規范

在我們開發過很多個項目之后，每個項目都會累積下很多源碼、文檔等，查找和整理起來很不方便，如果我們又要同時工作于多個項目的話，情況會更糟。所以對每個項目的各種檔案進行有效管理很有必要，從公司層面上來說，可以采用版本控制系統（例如VSS、CVS等）來進行管理，從個人來說，可以建立自己的一套文檔存放規范，減少文檔存放的隨意性，把各種項目檔案進行合理組織，方便以后的查找和整理。

以下就談談我的一些檔案組織方式和規則：

1、 由于項目開發過程中的各種文件都是比較小的，經常需要修改，時間久了，在硬盤上會產生不少的碎片，為了不影響系統效率，一般這些項目檔案文件都不和操作系統盤放在同一個目錄。

2、 由于一個項目一般都是多個人一起開發，為了保證每個人的開發環境一樣，一般把項目檔案文件存放在同一個盤符上，對于現在大多數電腦，一般的硬盤上都至少有兩個區，所以一般把項目文檔存放在D盤。

3、 為了不導致根目錄的膨脹，一般建立一個公司名稱目錄做為所有項目文檔、公司文檔的根目錄，例如：D:\TorrenSoft

4、 因為一個公司不可能只有一個項目，為了實現項目文檔和公司文檔區分對待，在公司名稱目錄下，再建一個Project目錄，存放各個具體項目。例如：D:\TorrenSoft\Project\CRM ，其中CRM就是具體的項目了。

5、 在公司名稱目錄下，建立Document目錄，存放公司的一些開發規范、制度等文件。另外還可以建立Library目錄來存放公司的各種通用庫文件；建立Resource目錄存放公司的其它各種資源文件，例如公司圖標等。

6、 在每個具體項目下，建立Backup、Document、Source、Help、Database、Release、Version等目錄來存放項目開發過程中的各種文檔。

7、 在項目名\Source下一般只存放當前項目的最新版本，如果需要同時維護一個項目的多個版本的話，把老版本放到Version下。

8、 為了最有效的管理各種文檔，最好在公司中建立一個版本控制管理系統，其目錄結構和以上描述的一致，這樣實現了公司和個人的目錄結構一致，維護起來就方便多了。

一個具體的項目存檔管理范例如下：

盤符＼TorrenSoft
以公司名稱作為所有項目的總目錄

TorrenSoft＼Document
這個目錄存放項目開發、程序開發、數據庫設計、文檔設計等開發規范，以及公司制度等。

TorrenSoft＼Library
存放所有項目的公共庫，如PBLib、JavaLib等

TorrenSoft＼Resource
公司的公共資源文件，也包括所有項目公用的資源文件，如位圖，光標，聲音等

TorrenSoft＼Project
所有項目的主目錄，以下存放各個具體的項目。

Project＼CRM
表示是客戶關系管理系統項目

Project＼RoadGIS
表示是公路GIS管理系統項目

Project＼FlexOA
表示是OA系統項目

項目名＼Document
項目名指的是以上說明具體項目，以下類似。

這個目錄存放此項目的一些文檔，如需求分析報告，系統流程圖，總體設計等．

項目名＼Backup
存放項目的文件備份，如舊的版本

項目名＼Source
存放此項目的源代碼

項目名＼Version
存放此項目的各種不同版本的文件

項目名＼Help
存放此項目的幫助文檔和操作手冊等

項目名＼Test
存放此項目的測試文檔和測試文件

項目名＼Database
存放此項目的數據庫，表結構、SQL語句等。

項目名＼Release
存放此項目的發布版本

基于中間件技術的多層分布式系統的研究

作者：趙洋 王芳 張玉新 馬建斌 來源：ahcit.com http://www.csai.cn 2005年09月13日
摘 要 從分布式系統的體系結構入手，介紹了中間件技術在多層分布式系統中的應用。針對基于 CORBA 、 COM/DCOM 、 EJB 三種中間件技術的體系結構和技術特點作了詳細介紹，并對三者的技術指標進行了比較。
關鍵詞 中間件；分布式系統；組件 ； EJB
1 引言
分布式系統的信息處理分布在許多計算機上而不是局限在單一機器上。目前一般類型的分布式系統體系結構可以分為兩種。一種是客戶機 / 服務器（ C/S ）體系結構，它由客戶端提供用戶界面、運行邏輯處理應用，而服務器接受客戶端 SQL 語句并對數據庫進行查詢，然后返回查詢結果。 C/S 結構曾給人們帶來許多便利，但隨著業務處理對系統提出更高要求以后，它也逐漸暴露出其客戶端逐漸龐大和服務器負擔過重的缺點，如靈活可擴展的工作流定制、保證數據在網絡傳輸的穩定性和準確性、應付峰值數據的高負荷處理和平衡負載等諸如此類的要求， C/S 結構就難以滿足。
2 多層分布式體系結構

為了解決兩層 C/S 分布式體系結構存在的不足，提出了三層或多層分布式對象體系結構，在這種情況下，業務邏輯從客戶端分離出來，移動到中間層。于是，在服務器和客戶機之間增加了業務邏輯層或其它應用服務層。系統就成為了具有客戶端的表示層、中間的業務邏輯層和數據庫服務器的三層或多層體系結構，如圖 1 所示：多層分布式系統體系結構的一般模型。多層體系結構將客戶和資源分開，降低了服務器的負載，避免了服務器的性能缺陷對整個系統性能的影響，在多個服務器上分布應用程序處理的多層可變結構比二層的體系結構的伸縮性和擴展性更強。
在多層分布式系統中，不同的組件可能用不同的語言來實現，且這些組件可能運行在不同類型處理器上。數據模型、信息表示法以及通信協議可能都不一樣。因此，多層分布式系統就需要某種軟件來管理這些不同部分，確保它們能通信和交換數據。中間件就是這樣一種軟件，它位于系統的不同分布式組件之間。
中間件能夠使應用系統相對獨立于計算機軟硬件平臺，為大型分布式應用搭起一個標準的平臺，把企業分散的系統技術組合在一起，從而實現企業應用軟件系統的集成。中間件具有標準的程序接口和協議，使不同硬件和操作系統平臺上分布式應用的數據共享和互操作。中間件在操作系統、網絡和數據庫之上，應用軟件之下，總的作用是為處于自己上層的應用軟件提供運行和開發環境，幫助用戶靈活、高效的開發和集成復雜的應用軟件。
隨著分布式技術和面向對象技術的結合，產生了大量基于分布式對象中間件的模型。目前主要的分布式系統中間件技術標準有： Microsoft 的 COM/DCOM 技術、 SUN 的 EJB 技術和 OMG （對象管理集團）的 CORBA （公共對象請求代理體系結構）技術為代表的三種基于中間件技術的分布式模型框架。
3 EJB 技術規范
EJB （ Enterprise Java Beans ）是 J2EE 的核心技術之一，它是建立基于 Java 的服務器端組件的標準。 EJB 是以部件為基礎框架，其中每個部件都是分布式對象，可以擴展，也可以適配在不同應用中使用，大大方便了企業應用開發。 EJB 不局限于一種特定的操作系統，也不局限于任何一種特別的機構、服務器解決方案、中間件或者通信協議，是一種可重用的具有高度可移植性的組件。 EJB 組件模型包含了 EJB 服務器、容器、 Home 接口、 Remote 接口等。
EJB 服務器是管理 EJB 容器的高端進程或應用程序，并提供對系統服務的訪問。 EJB 服務器實際是各種支持 EJB 安裝的服務的集合，這些服務包括分布式事務管理、分布式對象管理和這些對象的分布式調用以及低層次的系統服務。
EJB 容器是管理一個或多個 EJB 類和實例的抽象。它通過規范定義的接口使 EJB 類訪問所需的服務。 EJB 容器管理 Enterprise Bean 對象的生命周期，協調分布式事務和實現對象安全性。
遠程接口（ Remote Interface ）列出了 EJB 類中的商業方法。 EJBObject 實現遠程接口，并且客戶通過它訪問 EJB 實例的方法。 EJB 類開發者定義遠程接口，容器開發商提供產生相應的 EJBObject 的方法。客戶端不能得到 EJB 實例的引用，只能得到它的 EJBObject 實例的引用。當客戶端調用一個方法， EJBObject 接收請求，把它傳給 EJB 實例，同時提供進程中必要的包裝功能。客戶端應用程序通過 Home 對象來定位、創建、刪除 EJB 類的實例，通過 EJBObject 來調用實例中的商業方法。
Home 接口列出了所定為、創建、刪除 EJB 類實例的方法。 Home 對象是 Home 接口的實現。 EJB 類開發者必須定義 Home 接口。容器廠商應該提供從 Home 接口中產生 Home 對象的實現方法。
EJB2.0 規范定義了三種不同的企業 Bean ，分別是會話 Bean 、實體 Bean 和消息驅動 Bean 。會話 Bean 主要負責模擬商業過程，實現商業邏輯，處理商業規則和工作流。會話 Bean 又分為兩個子類，無狀態會話 Bean 和有狀態會話 Bean 。實體 Bean 表示持久數據，為商業數據建模。按持久性劃分，實體 Bean 又可以分為自管理的持久性實體 Bean 和容器管理的持久性實體 Bean 。消息驅動 Bean 和會話 Bean 相似，也執行一些商務邏輯，其區別在于只能夠通過給這些 Bean 發送消息來調用它們，且實現了異步處理機制。從分布式計算的角度看， EJB 即提供了分布式技術的基礎，又提供了對象之間的通信手段。
EJB 技術的特點： ① 可移植性。由于 EJB 規范頒布了一組明確的 EJB 容器和 EJB 組件之間的契約，這保證了 EJB 組件在不同 EJB 服務器上可移植性。 ② 平臺獨立性。 EJB 體系結構完全獨立于任何特定的平臺、協議和中間件等基礎設施。一個平臺上開發的應用程序不做修改就可以移植到另一平臺，完全實現了“一次編寫，處處運行”的目的。 ③ 簡化了分布式對象的開發、部署和訪問。 EJB 分布式對象的開發人員只要按照 Enterprise Java Bean 建立的契約和協議實現對象。這使整個開發和管理變得簡單，大大降低系統建設成本、減小開發周期。
4 CORBA 技術規范
CORBA 是 OMG 組織在 1991 年提出的公用對象請求代理程序結構技術規范。 CORBA 有很廣泛的應用，它易于集成各廠商的不同計算機，從大型機一直到微型內嵌式系統的終端桌面，是針對大中企業應用的優秀體系結構。
CORBA 的底層結構是基于面向對象模型的，由 OMG 接口描述語言（ OMG Interface Definition Language, OMG IDL ）、對象請求代理（ Object Request Broker, ORB ）和 IIOP 標準協議（ Internet Inter-ORB Protocol ）３個關鍵模塊組成。
使用接口描述語言編寫的對象接口，使得與語言無關的獨立性成為可能。 IDL 使得所有 CORBA 對象以一種方式被描述，僅僅需要一個由語言（ C/C++ 、 CORBA 或 Java ）到 IDL 的“橋梁”。 CORBA 對象的互通要以對象請求代理為中介，這種互通信可以在多種流行通信協議之上實現。在 TCP/IP 上，來自于不同開發商的 ORB 用 IIOP 標準協議進行通訊。
為了保持 CORBA 的商業中立性和語言中立性，必須有一個中介，存在于像 C++ CORBA 服務器代碼和 Java CORBA 客戶機這樣的實體中間，這就是 IDL 。一個底層對象的若干相關方法和屬性被 IDL 集入一個單一接口。一旦 IDL 接口定義完成，它可以以 Sub 碼或框架代碼的形勢編譯成所選用的語言。在所有的 ORB 中都有 IDL 編譯器。 IDL 不同于其它的面向對象程序設計語言，我們不能用它指定所定義的類或方法的具體實現。 IDL 是一種描述性語言而不是編程語言，用它定義底層對象接口，使得接口定義與對象實現分開。 IDL 編譯器編譯 IDL 代碼，生成相應語言的頭文件及客戶代理和服務器代理對象。
CORBA 技術規范利用了當今軟件技術發展的最新成果，在基于網絡的分布式應用環境下實現應用軟件的集成，使得面向對象的軟件在分布、異構環境下實現重用、可移植和互操作。其特點如下： ① 在 CORBA 規范中引入了代理（ Broker ）的概念，一個代理至少可以完成對客戶方提出的抽象服務請求的映射；自動發現和尋找服務器；自動設定路由，實現到服務器方的執行。 ② 實現客戶與服務對象的完全分開，客戶不需要了解服務對象的實現過程以及具體位置。 ③ 應用程序間的統一接口。 CORBA 提供軟總線機制，這是系統定義的一組接口規范，使得在任何環境下，采用任何語言開發的軟件只要符合接口規范的定義，均能集成到 CORBA 系統中。 ④ CORBA 采用面向對象的軟件實現方法開發應用系統，實現對象內部細節的完整封裝，保留對象方法的對外接口定義。 ⑤ 分層的設計原則和實現方式。 CORBA 規范只是針對 OMA 體系結構中的 ORB 制定的工業標準，而面向對象定義則可以在 OMA 的應用對象或應用開發環境中逐步分層定義和實現。
5 COM/DCOM 技術規范
COM （ Component Object Model ，組件對象模型）是 Microsoft 軟件組件標準，是構造二進制兼容軟件組件的規范。 COM 的體系結構包括統一數據傳輸、持久存儲和智能命名、 COM 核心等。其中 COM 核心包括服務控制管理、接口代理、接口基和 COM 庫。 COM 核心定義了 COM 對象與使用者如何通過二進制標準接口進行交換的規格說明。持久存儲通過 Istorage 和 Istream 接口提供一個“文件系統”。智能命名通過對象實現接口，使用戶可以在以后重新連接一個指定的對象實例，并且使對象實例仍保持原來的狀態，另外還提供保存它們名字和其它持久信息的機制。 COM 庫提供對所有客戶及組件都非常有用的組件管理服務。
DCOM 是 COM 的分布式擴展， Microsoft 把 DCOM 作為開發 Internet 和組件的基礎。當客戶和組件位于不同機器時， DCOM 用 TCP/IP 協議等取代 COM 中的本地進程間通信 LRPC ，從而對位于 Internet 不同機器上的組件對象之間的相互通訊提供了透明的支持。
COM/DCOM 技術具有以下特點： ① 語言無關性。 COM 規范的定義不依賴于特定語言，它采用的是一種二進制代碼級的標準，而不是源代碼級的標準。 ② 可重用性。 COM 重用性是建立在組件對象的行為方式上的，它指示了 COM 對象如何重用已有的 COM 對象功能。有兩種途徑：包容和聚合可實現 COM 重用性。 ③ 位置透明性。組件從一臺計算機轉移到另一臺計算機僅涉及到重新配置的問題，不涉及到一個大的開發項目。
6 結論
中間件的目標就是掩蓋底層的異構性，方便編程。因此理想的中間件應該提供對多種程序設計語言的支持，有良好的跨平臺能力，同時還具有網絡透明性、位置透明性和訪問透明性等特點。
支持跨平臺能力是 CORBA 的一大特色。基于 CORBA 開發的應用，完全避免了底層平臺的不一致所帶來的問題，它支持 Unix 、 OS/2 等眾多平臺。 EJB 是依賴于 Java 語言的技術，由于 Java 的平臺無關性，使得 EJB 可以運行在不同的開發平臺上。 COM/DCOM 僅實現了 32 位 Windows 操作系統平臺，這使得跨平臺支持帶來了困難。
在語言支持方面， CORBA 一開始就設計了 IDL 轉換標準語言，所以對于大多數面向對象的語言 CORBA 都支持。 COM/DCOM 也具有語言無關性，只有 EJB 是基于 Java 語言的，但由于 Java 的廣泛使用， EJB 技術也得到越來越多開發者的喜愛。
總之， 3 種中間件技術都有其優勢， Java 由于平臺無關性的優勢顯著，成為理想的 Internet 技術；而 Windows 平臺的廣泛使用也使 COM/DCOM 具有深厚的基礎； OMG 組織在 10 幾年來一直在為自己的組件軟件建立標準，而且已被很多組織和公司采用。對于異構環境下的分布式組件和服務的性能模式

轉載于:https://www.cnblogs.com/sanle/archive/2006/03/04/342840.html

總結

以上是生活随笔為你收集整理的项目存档管理规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。