【正文】 ，否則不 檢查改實體的實例是否引用了將要被刪除的實體 。 在關(guān)聯(lián)關(guān)系中也需要定義級聯(lián)修改檢查規(guī)則 。當修改校驗被設(shè)置為 true 時， 該 關(guān)聯(lián)關(guān)系的被引用實體 的實例 修改時，引用它的實體將被納入 到引用檢查范圍內(nèi)，否則不檢查該類型的實體實例是否引用了需要修改的實體實例。 服 務模型 服務模型用于描述業(yè)務邏輯處理的接口信息。 服務模型可以定義服務和業(yè)務操作兩種接口，在模型上需要定義參數(shù)、返回值以及可能拋出的異常。同時還需要指定對數(shù)據(jù)庫事務的支持方式。當一個服務接口可以有多種實現(xiàn)策略時，可以定義多個策略。當然策略的選擇邏輯需要開發(fā)人員在隨后的開發(fā)過程中通過編程實現(xiàn)。 服務與業(yè)務操作的差異是與軟件的部署方式和應用組件的邊界相關(guān)的。 UBF 提出了服務組的概念 ，一個服務組是指一組具有高度耦合性的業(yè)務組件，它們在安裝部署時具有不可分割的整體性。因此當開發(fā)人員準備調(diào)用另外一個服務組內(nèi)的組件提供 的功能時，只能通過聲明為服務類型的接口調(diào)用，而在服務組內(nèi)組件間的相互調(diào)用通常使用業(yè)務操作。注意這種劃分并不僅僅與是否支持遠程調(diào)用有關(guān)，通常無論服務還是業(yè)務操作都支持遠程調(diào)用。 界面模型 界面模型用于描述應用的交互界面。它包括表單數(shù)據(jù)模型、表單模型、參照模型及表單模版。 表單數(shù)據(jù)模型 表單數(shù)據(jù)模型（ UIModel）用于開發(fā)者定義界面的數(shù)據(jù)模型。它由一個或多個視圖（ UIView），以及視圖間的連接關(guān)系（ UILink）和動作（ Action）組成。 每個視圖可以關(guān)聯(lián)一個數(shù)據(jù)來源 —— 目前我們僅支持實體作為數(shù)據(jù)來源， 視圖下包含數(shù)據(jù)項（ UIField）以及這些數(shù)據(jù)項的分組（ Group）和 缺省的數(shù)據(jù)篩選條件 。 數(shù)據(jù)項通常綁定到該視圖所關(guān)聯(lián)的實體的屬性上，當然開發(fā)者也可以建立沒有任何綁定關(guān)系的數(shù)據(jù)項以用于存儲交互邏輯需要的臨時性數(shù)據(jù)。 缺省的數(shù)據(jù)篩選條件是開發(fā)者在設(shè)計階段用 OQL 定義的缺省數(shù)據(jù)加載條件，可以通過代碼動態(tài)的修改。 動作用于開發(fā)者設(shè)計界面的功能行為，通常 UBF 的設(shè)計工具會缺省地預置一些常用行為，如保存、刪除、查找等。 表單模型 表單模型（ Form）用于開發(fā)者定義用戶界面，如顯示內(nèi)容、布局 、前端控制行為等。在表單模型 中 UBF 提供了 30 種是用于 ERP 軟件開發(fā)領(lǐng)域的控件，其中有數(shù)據(jù)錄入型的控件也有前端行為控制用的關(guān)聯(lián)控件。每個控件都有數(shù)據(jù)來源的綁定信息，通常都來源于表單數(shù)據(jù)模型，特殊 情況下開發(fā)者可以不綁定 UIModel，在代碼中實現(xiàn)控件內(nèi)容的管理。 表單模型上 由關(guān)于 Portal 整合時使用的表單關(guān)聯(lián)方面的信息。其中 Form 參數(shù)用于定義表單接收的參數(shù) ，而提供者集合用于定義表單可以提供的參數(shù)。 參照模型 參照模型是輕量的表單數(shù)據(jù)模型和表單模型的復合體。因為 大多數(shù)參照頁面無論是界面風格還是表單數(shù)據(jù)模型的結(jié)構(gòu)都具有相似性，唯一定義 的僅僅是表單數(shù)據(jù)模型中視圖所關(guān)聯(lián)的實體和數(shù)據(jù)項以及過濾條件，因此 UBF 提供了這個簡化版的模型以方便開發(fā)工作。 如果開發(fā)者需要定義一些特殊的參照頁面，可以使用表單數(shù)據(jù)模型和表單模型像開發(fā)頁面一樣去開發(fā)參照頁面。 表單模版 表單模版用于表單模型的重用目的。通常有一些頁面大體相似，僅有一些局部的差異，開發(fā)者可以為相同的部分設(shè)計表單并生成表單模版，然后在開發(fā)表單模型時套用該模版。注意模版套用是一種復制動作，因此對模版的任何修改都將不會影響已經(jīng)套用了該模版的表單。同時 在一個表單上只能在模型創(chuàng)建時進行 模版套用 動作。 應用組裝模型 應用組裝模型用于描述應用的整體結(jié)構(gòu)。包括應用領(lǐng)域的多級劃分，每個應用下包含的前后臺組件 、 應用的功能菜單結(jié)構(gòu) 、 應用的頁面。 應用模型 用于軟件開發(fā)者以樹狀結(jié)構(gòu)規(guī)劃其開發(fā)的軟件產(chǎn)品。 開發(fā)者將其開發(fā)的業(yè)務組件和界面組件規(guī)劃到每個應用中。作為支持組件化開發(fā)和交付的平臺， UBF 為軟件開發(fā)者提供了從應用功能和客戶價值角度描述其軟件產(chǎn)品的模型。 依據(jù)該模型所提供的信息，軟件開發(fā)者可以實現(xiàn)相應的安裝和許可證策略，以及組件間接口銜接的策略，為達到按需交付提供有力的支持。 頁面模型 頁面模型用于定義在 Portal 上顯示的 Page 的信息。每個頁面上可以定義一個或多個表單，頁面內(nèi)的布局支持條帶式布局方式，即一個頁面內(nèi)可以有一個或多個條帶，每個條帶內(nèi)可以放置多個表單，按次序從上向下自然排布。條帶的寬度由開發(fā)者指定，不會因內(nèi)部表單的尺寸而發(fā)生伸縮，但高度不能確定，由所有內(nèi)部表單的高度綜合確定。 在頁面模型內(nèi)可以定義表單間的關(guān)系，即將一個表單的提供者參數(shù)與另一個表單的接收參數(shù)間建立綁定關(guān)系。這樣當提供方表單的數(shù)據(jù)發(fā)生變化時可以引發(fā)接收方產(chǎn)生相應得變化。 UBF 運行平臺 基礎(chǔ) 服務 UBF 底層是一組基礎(chǔ)服務支撐 UBF 運行平臺和 其上的應用軟件的運行。包括上下文管理、配置服務、 日志服務、國際化異?？蚣?、悲觀鎖服務、 服務會話 管理、資源服務、 Cache 服務、數(shù)據(jù)庫連接服務、數(shù)據(jù)庫事務 管理、 OQL 引擎、表達式引擎、 事件引擎和異步調(diào)度引擎 。 服務會話管理 服務會話管理工作在 Portal 或應用服務器的服務線程上 ，監(jiān)視服務線程的進入和退出。 ? 提供統(tǒng)一的線程靜態(tài)變量存儲管理，在離開線程時負責清理。 ? 提供線程級的緩存管理； ? 提供線程上的服務或業(yè)務操作調(diào)用棧監(jiān)控，以防止 出現(xiàn)無限制的迭代調(diào)用。 ? 提供服務或業(yè)務操作的上下文環(huán)境，并在其中提供服務級的緩存管 理。 上下文服務 工作在服務會話上，提供應用的上下文環(huán)境管理。 UBF 維護基本且必須的應用上下文，包括企業(yè)、組織、登錄用戶、登錄日期、 當前語言文化、用戶登錄的會話標識符。這些上下文信息初始來自用戶登錄時， UBF 將其緩存在 Portal 的 session 中，并響應用于的請求時設(shè)置到工作線程上。當調(diào)用遠程服務時， UBF 負責將上下文傳遞到遠端的工作線程上。 開發(fā)人員可以增加自定義的上下文信息。 悲觀鎖服務 悲觀鎖服務提供非等待的并發(fā)控制機制 —— 即一旦加鎖 不成功將立即返回 。 UBF 提供了進程內(nèi)和分布式兩種實現(xiàn)策略，當僅部 署一個應用服務器時應當配置使用進程內(nèi)實現(xiàn)策略，所有的鎖都在進程內(nèi)管理，以提供最佳的運行效率。當部署為多服務器集群時，應當配置使用分布式實現(xiàn)策略，所有的鎖信息都在數(shù)據(jù)庫表中管理 。 悲觀鎖支持共享和獨占（讀 /寫）兩種鎖定級別。共享鎖允許有多個所有者同時鎖定同一個對象，以用于防止讀取已經(jīng)過期的數(shù)據(jù)。獨占鎖僅允許一個所有者加鎖，以用于變更數(shù)據(jù)定意圖。 悲觀鎖允許同一所有者對同一對象反復加鎖，當然也要進行相應次數(shù)的解鎖。當所有者已經(jīng)擁有鎖的情況加，可以通過加獨占鎖進行鎖升級，但有可能加鎖失敗。 事件引擎 事件引擎 用于實現(xiàn)事件發(fā)布訂閱機制，以滿足某些業(yè)務需求。 ? 事件訂閱可以是臨時或持久的。 ? 事件處理器可以指定過濾條件，僅當條件滿足時，事件處理器才會被調(diào)用。 ? 事件處理器可以被同步或異步地調(diào)用。 ? 事件處理器的錯誤處理行為可以指定為容錯或是立即報告。 ? 所有這些事件處理器的行為都可以通過屬性 (Attribute)或是訂閱參數(shù)來指明。 ? 開放的體系結(jié)構(gòu)，可以很容易擴充基于消息的，分布式的事件系統(tǒng)功能。 異步調(diào)度引擎 調(diào)度引擎用于滿足后臺的定時任務需求。 ? 標準異步調(diào)用，具有可實時查詢狀態(tài)，可靠性等功能增強。 ? 任務定時調(diào)度，可實時 查詢請求執(zhí)行狀態(tài)，任務定義持久化。 ? 靈活的周期性定時策略，可隨意組合年，月，周，日，小時，分，秒七級定時單位。 ? 支持即時啟動策略 ? 每個定時單位可以按區(qū)間，周期間隔，離散時間點集合，定點時間四種策略指定。 ? 支持多種可執(zhí)行邏輯的表達，包括委托，指定方法名，定制實現(xiàn)接口。 ? 開放的體系結(jié)構(gòu)，可擴展定時策略、可執(zhí)行邏輯接口等等。 國際化異?？蚣? 模型設(shè)計階段設(shè)計的業(yè)務異常，在生成代碼時 UBF 將其生成為符合國際化異?？蚣艿漠惓ｎ悾瑫r也支持編程方式實現(xiàn)。 ? 任何符合國際化異?？蚣艿漠惓?UBF 可以將其透明地傳遞到遠端。 ? 依據(jù)當前上下文中語言文化的標識或去相應語言的信息 數(shù)據(jù)庫連接服務 UBF 運行平臺支持多企業(yè)、多組織的應用在同一個應用服務器實例上運行。而不同的企業(yè)不能對應相同的數(shù)據(jù)庫。因此 UBF 的數(shù)據(jù)庫連接服務將依據(jù)當前上下文中企業(yè)的信息獲取正確的數(shù)據(jù)庫連接，而不用開發(fā)人員關(guān)注多企業(yè)導致的多數(shù)據(jù)庫問題。 實體開發(fā)框架 實體 （ BE） 的基本概念 BE，即 Business Entity，指領(lǐng)域模型中的業(yè)務數(shù)據(jù)對象，如：訂單頭，客戶，地址，國家等 BE 的設(shè)計工作通過 UBF Studio 完成。 在一個模型圖中，我們會設(shè)計實體，屬性類 型，枚舉類型，關(guān)聯(lián)，繼承，組合，效驗，異常，事件等等相關(guān)的東西 。 實體的對外結(jié)構(gòu)基本組成 每一個強類型的實體都有以下幾個類： 實體 類，如 A_Ass1to1 實體的 Key（強類型的 EntityKey） : 實體的查詢類 Finder： 實體的強類型集合 EntityList： 實體的資源屬性和強類型訪問屬性的輔助類 實體弱類型的 EntityKey 弱類型 EntityKey 是 BusinessEntity 的內(nèi)部類，也是強類型 EntityKey 的基類，主要涉及標識一個實體兩個關(guān)鍵的屬性： ID 和 EntityType，并對外提供一個 GetEntity()的公開方法 實體內(nèi)部數(shù)據(jù)存儲 在實體內(nèi)部，自身的數(shù)據(jù)為基本類型，保存在集合 InnerData 中，關(guān)聯(lián)數(shù)據(jù)為對象或集合類型，保存在集合 InnerRelation中。這兩個對象都提供了一些事件和方法，如 GetValue/SetValue，GetRelation/SetRelation 等用來對實體進行較高級的控制（如弱類型操作）。由于強類型的方式使用 BE 比較簡單 直觀，在生成實體代碼時，會提供強類型的訪問方式，所以，開發(fā)人員一般不會直接訪問實體的內(nèi)部數(shù)據(jù) 實體的 CopyTo 為了支持實體數(shù)據(jù)的復制，可以利用 ICopyable 接口，基類 Entity 支持該接口，可以通過實例方法 CopyTo，將實體中的數(shù)據(jù)復制給 target。 CopyTo 對外提供兩種方法： CopyTo(Entity target)，這種方式默認是不拷貝 ID CopyTo(IPersistableObject po, bool isCopyKey),這種方式可以由第二個參數(shù)決定是否要拷貝ID 注意： 目 前 CopyTo 方法只完整實現(xiàn)了對基本屬性的拷貝，對于關(guān)聯(lián)實體，實際上是不拷貝的，對于一對一或一對多的情況，會出現(xiàn)關(guān)聯(lián)對象也拷貝的假象，實際上，對象是懶加載上來的，對于一對多的情況，是空對象，以后根據(jù)實際的使用情況，決定是不是要完整實現(xiàn)關(guān)聯(lián)實體的拷貝 CopyTo 方法只是將相關(guān)的業(yè)務數(shù)據(jù)拷貝，不涉及到一些系統(tǒng)的控制屬性，如 SysState，NeedPersistable 等系統(tǒng)的控制字段 ,不涉及到 OriginalData 實體的 OriginalData 實體帶有一個 OriginalData 的屬性，保存實體在數(shù)據(jù) 庫中的原始值， OriginalData 反映的是實體在數(shù)據(jù)庫中的映像，初始值是一個空的實體對象，只有在查詢，新建和修改操作成功后，才會刷新 OriginalData，保持和數(shù)據(jù)庫一致，需要詳細說明的是，新建和修改時刷新OriginalData 的動作在基類的 OnInserted 事件和 OnUpdated 事件之后，所以，在生成的 XXX 文件中，如果在后事件中要訪問舊值，需要注意前后順序 通過實體的 GetChangedAttributes 方法可以 返回變化后的簡單屬性的集合，注意是簡單類型，不包括集 合屬性，屬性類型 。 示例： using (ISession s = ()) { Yel_Ass1to1_A a = ()。 = OldValue。 ()。 a = (ID = + )。 = NewValue。 (1, ().Count)。 = 123。 (2, ().Count)。 = aaa。 (2, ().Count)。 = OldValue。 (1, ().Count)。 ()。 ()。 } 這里有幾個需要提醒開發(fā)人員注意的事項： ? OriginalData 刷新的時機： 對于新建和修改操作， OriginalData 是在 OnInserted/OnUpdated 方法運行完后刷新，對于查詢， Origin