元件（基本元件、業務元件...）
簡介
元件（Component）是對資料和方法的簡單封裝。C++ Builder中，一個元件就是一個從TComponent派生出來的特定物件。元件可以有自己的屬性和方法。屬性是元件資料的簡單訪問者。方法則是元件的一些簡單而可見的功能。使用元件可以實現拖放式程式設計、快速的屬性處理以及真正的面向物件的設計。VCL和CLX元件是C++ Builder系統的核心。
元件分類
自己開發的元件通常有三種類型：複合元件（Composite Controls），擴充套件元件（Extended Controls），自定義元件（Custom Controls）。
複合元件：將現有的各種元件組合起來，形成一個新的元件，將集中元件的效能集中起來。
擴充套件元件：在現有元件的元件的入門上派生出一個新的元件，為原有元件增加新的效能或者更改原有元件的控能。
自定義元件：直接從System.作windows.Forms.Control類派生出來。Control類提供元件所需要的所有入門效能，包括鍵盤和滑鼠的事件處理。自定義元件是最靈活最強大的辦法，但是對開發者的要求也比較高，你必須為Control類的OnPaint事件寫原始碼，你也可以重寫Control類的WndProc辦法，處理更底層的作windows訊息，所以你應該學習GDI+和作windows API。
第三方控制元件
元件開發者應該掌握的三項主要內容是：屬性、事件和方法。
由於元件開發複雜度較高, 專業第三方控制元件 會重寫或者拓展了一些方法和屬性，從而能實現某些新的功能，同時他們有較大的可定製性，可以根據使用者的需要設定不同的特性，從而完全適應特定專案的需求。常見的第三方控制元件包括表格控制元件、報表控制元件、使用者介面控制元件等。
使用者介面元件
用於開發構建使用者介面（UI）的元件，幫助完成軟體開發中視窗、文字框、按鈕、下拉式選單等介面元素的開發。
圖表元件
用於開發圖表的元件，幫助軟體實現資料視覺化，實現開發時較難獨立完成的複雜圖表。
代表：ComponentOne Studio Chart for WinForm。
報表元件
用於開發報表的元件，在軟體中實現報表的瀏覽檢視、設計、編輯、列印等功能。
代表ActiveReports等。
表格元件
專門用於開發表格（CELL）的元件，主要實現網格中資料處理和操作的功能。
代表：FlexGrid、Spread等。
業務元件
業務元件是一系列不可分割的業務活動，是構建專業化企業的功能模組。業務元件的優勢在很大程度上來源於其具備兩個相關但截然不同的特性：首先，元件之間通過鬆散耦合方式進行連結，具備靈活、響應快、適用能力強的特點；其次，元件內各活動的凝聚力強，可對外提供效率高、質量好的服務。
將業務活動歸類為元件時需要考慮的因素有：
● 相似的業務活動
● 使用類似的資料
● 具有通用的處理流程
● 通用的業務目標
● 是密切聯絡的組織單元 通過元件共享，企業可以顯著地改善運營效率並提高差異化競爭優勢。
需要深入瞭解業務之間的關係，並根據企業的戰略、管理和執行各層面要求來進行歸類劃分。這需要有很好的業務分級分類能力，並考慮到業務間的資料流向和共享。 業務元件的劃分這一步做好了，系統功能設計和原型設計也就容易了！
企業應用下的業務元件開發實踐
什麼是企業應用下的業務元件
首先，這是一個元件，這意味著它需要在容器裡執行，因此不包括任何中介軟體服務，同時以一定結構（檔案結構或者壓縮格式）組成，被容器識別；其次，這是一個業務元件，即提供的是應用服務，而非技術服務；第三，這是企業應用，在業務上包括功能和服務（Service，當前最時髦的說法，你可以理解為API），技術上（以J2EE來講）包括：UI資源（JSF、JSP、JS和CSS等）、應用程式（Java）資源和配置檔案、資料庫表定義、初始化資料和儲存過程。
為什麼要企業應用下的業務元件
元件技術從提出到現在已經有20多年了，為什麼要提企業應用業務元件？因為現有的元件技術不支援企業應用環境下的元件要求，J2EE的EJB不支援，.NET的DLL也不支援。
如前所述，一個企業應用通常包括了互動介面、應用程式碼以及資料庫結構，而不論是EJB還是DLL只支援應用程式碼，都不包括互動介面和資料庫結構。
如果說EJB不是，那麼J2EE的EAR或者WAR是否算是一個元件？答案也不是，EAR或者WAR部署的是一個企業應用，請注意EJB規範中明確說：The Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications(EJB 2.x和3.x唯一的區別是2.x有distributed），它們有自己的應用域，彼此相互隔離（簡單的看，它們有各自獨立的會話管理）。.NET也是有自己的應用域概念。
更進一步，基於應用的部署導致了三個隔離問題：互動（介面）隔離、程式訪問隔離和資料隔離（請注意這三個問題分別對應了企業應用業務元件的三個技術內容）。互動隔離導致了企業使用者必須訪問不同介面，程式碼訪問隔離導致了點對點的整合以及諸如效能、事務和非同步處理等各種非功能性問題，而資料隔離導致了資料有效性、一致性等等問題。所有這些都進而導致了維護的問題。
為了解決這些問題，大廠商們都提出了各種解決方案：Portal來解決互動隔離問題，通過ESB來解決程式碼訪問隔離問題，以及通過所謂的資訊服務（Information Service）來解決資料隔離問題。
那麼OSGi技術或者SCA技術能否滿足要求？答案是目前不能，OSGi最初開發的目的就不是為了企業應用，只是這幾年開始成熟，並向企業應用方向發展。09年推出的企業版（草案）剛剛提出針對程式訪問問題的方案，如遠端服務、事務管理等；互動隔離問題上規範並沒有提出相應方案，只有Eclipse的Equinox提出了介面的擴充套件點機制，但這也不能解決B/S環境的問題；而資料隔離問題就沒有任何方案。SCA從一開始就是面向企業應用，不過不解決互動隔離和資料隔離問題。
此外，對於行業ISV來說，除企業使用者面臨的這些種種問題，還面臨著其它問題。企業使用者畢竟只是面對自己的需求，行業ISV卻面臨著多個企業使用者的需求，面臨定製化帶來的維護問題，特別是業務和技術的隔離問題（即如何保持構建業務元件的所使用技術的平穩升級）。
元件的容器
既然要企業應用下的業務元件，而現有的元件技術又無法支撐，那麼就需要一個新的元件容器了（當然，作為一個普通開發人員，我們無法新建一個公開標準的元件體系，也獨立維護一個私有的）。新的元件容器完全使用現有的中介軟體技術，並加上一些新的內容，包括如下：
1.元件框架，識別元件，以及元件（檔案）結構和各個技術工件。
2.技術框架，提供業務無關的技術支援，以便於技術的平穩升級切換。
3.執行容器，採用現有中介軟體技術，包括Tomcat、應用伺服器和資料庫服務等；
4.工具，包括打包以及部署工具等。
關於資料隔離問題，在EIP中提到了各種解決方案，這裡採用的共享資料庫方式，即各個元件都共用一個數據庫，各個元件只提供資料庫定義和初時資料（如同EJB/OSGi一樣，執行時環境由容器提供）。
元件的關係
元件的關係分為兩種：依賴和聯動。依賴關係在已有的元件技術上已經廣為認知，而聯動則是新創造的（肯定不是第一個建立的，只不過不同人有不同的叫法）。
聯動和依賴的區別是：如果有元件B和元件A聯動，則元件B可以在沒有元件A的情況下執行，並提供相應功能。
針對三種不同技術工件（即三個隔離問題）呈現不同特點，如下：
UI資源（互動隔離問題），依賴是指UI資源的嵌入、引用和替換，聯動是指UI資源的新增。
應用程式（程式訪問隔離），依賴是指API/模型依賴，聯動是指訊息（傳統訊息和JMS訊息）以及SPI實現。其中，無論是依賴或者聯動都涉及到相應的非功能性需求，包括：非同步、事務控制和服務時限等。
資料庫資源（資料隔離），依賴是指外來鍵關聯和級聯操作，無明顯的聯動關係。
這裡，需要關注應用程式的依賴和聯動
- SPI和API存在業務不匹配問題。
雖然元件A依賴元件B，但是不代表元件B提供的服務完全匹配元件A的要求。有時元件A所需要的資料需要元件B的多個API組成，為了開發方便或者元件A所需要的效能問題，可能會在元件B新寫一個介面給元件A使用，注意該介面不是元件B的API，該介面僅適用於元件A。
- 儘可能的使用SPI整合方式
SPI整合方式是相對於API整合方式，API整合方式就是，元件B直接呼叫其它元件的API及其模型。SPI整合方式（類似於依賴倒置），元件B定義其所需要的介面及其模型，由元件A或者膠水層程式碼來實現。
這個點對於行業ISV尤為明顯。對於企業使用者來說，依賴是明確的，元件A依賴/聯動於元件B，但對於行業ISV，則面臨著定製化問題，雖然元件A依賴/聯動於元件B，但是在某個定製化專案中，由於客戶已有系統C，而需要元件A依賴/聯動於客戶已有系統C。此時採用SPI方式。
在開源世界裡採用SPI方式更是廣泛。很多框架為了相容（同一功能）不同實現的類庫，都是先定義框架所需介面，並同時提供不同類庫的膠水程式碼。
不論是EJB/OSGi/SCA都沒有對SPI整合方式的支援。
- 依賴和聯動的非功能性需求。
事實上，非功能性需求都是在整合時才存在的。以事務管理為例，除了及其少數的例子外，大部分事務只能在處理流程才被決定（注意，EJB在這方面著是定義在API上的，這樣的設計是不適應需求的），而元件A的API在用例1中需要被非同步呼叫，而在用例2中需要被同步呼叫是常見的。即便是OSGi規範，也在這方面沒有任何處理。
元件的定製化
定製化問題只針對於行業ISV有效，對於企業使用者來說，除非是那種跨國企業在面臨不同國度的業務模式、法律監管和會計制度等差異，存在定製化需要，即使如此，ISV和企業使用者對於同一問題的解決方式也是不同的。
既然我們已經將原有的應用採用元件化方式開發，那麼應用的定製化問題就轉化為元件的定製化問題。同樣，應用的定製化手段也就轉化為元件的定製化手段。
元件框架
羅羅嗦嗦的說了半天，有人就說了：這不就是把UI、Java和資料庫三個東東一打包，然後說這就是一個企業應用下的業務元件，有啥新意呢，不就是模組化開發嘛，一直一來大家都是就是這麼搞的嘛，何必搞個怪名詞來忽悠。
是的，就是把UI、Java和資料庫三個東東整合在一起，元件容器說提到的技術框架很多的開發隊伍都有一套，執行容器更是有無數開源商業的，打包部署工具更是寫了無數。
這確確實實就是我們常說的模組化開發。但是模組化開發不同於元件開發，模組化開發只是在邏輯上做了切分，物理上（開發出的系統程式碼）通常並沒有真正意義上的隔離，一切都只是在文件中。
我們需要一點乾貨，只有實實在在的元件框架才能元件化開發真正落地的（如同OSGi框架那樣）：我們需要一個類似於Equinox的介面擴充套件框架來支援UI資源的依賴和聯動；我們需要一個整合框架來支援應用程式的依賴和聯動，解決所面臨的種種問題（業務不匹配、SPI整合以及各種非功能性需求）；我們需要一個打包部署工具（類似Spring DM）提供部署UI資源、應用程式和資料庫定義資源（Spring DM提供了基於Web資源的部署能力）。
其它問題
對於採用J2EE下B/S環境的元件應用還面臨一個問題，即現有Servlet規範只允許一個web.xml，不支援元件各自定義私有的Filter和Servlet，不過這個問題不是很嚴重，在現有技術框架已經支援一份簡單的web.xml，而新的Servlet規範已經允許多個web.xml。
分散式部署以及叢集部署問題，這其實不是個問題。基於應用的我們有很多手段和技術，那麼基於元件的也一樣有辦法。