WebObjects/EOF/建模/EOModeler
它確實存在，以前也在這裡（連結現在失效了）：http://developer.apple.com/documentation/WebObjects/UsingEOModeler/4WorkingWithAttributes/chapter_4_section_3.html#//apple_ref/doc/uid/DontLinkBookID_504-DontLinkChapterID_3-BABFGECE
這是最令人煩惱和困難的領域之一。主要問題是生成的程式碼與您自己的業務邏輯分離。
以下是一些處理此問題的方法
這非常危險，因為每次您對模型進行一些修改時都需要進行合併。我從未設法在沒有大量汗水的情況下使其工作。
這是我大部分時間使用的方法。對於每個實際實體，您在模型中建立兩個實體：一個包含業務邏輯，另一個包含所有訪問器。訪問器實體是一個抽象實體，是實際實體的父級。實際實體是您的應用程式將與之互動的實體，永遠不需要重新生成。抽象實體用於承載所有訪問器，您可以在需要時重新生成它，因為它不承載任何您的程式碼。
所有關係必須與實際實體建立，否則您將遇到問題
此解決方案只有一個額外的技巧，嘗試透過在所有抽象實體前面新增一個通用字首來將它們放在一起。這樣您就可以選擇所有這些實體並使用一條命令重新生成它們（幾乎需要確認覆蓋確認）。
此工具使繼承技巧透明。有關更多資訊，請閱讀EOGenerator部分。
儘管在使用 EOModeler 時，使用 EOGenerator 或上述其他方法來建模您的 EO（使用 GenerationGap 設計模式）很有幫助，但這意味著您需要處理兩倍數量的 EO 類，以及更多在執行時向上繼承層次結構的訊息，以及更多需要簽入/簽出 CVS 的檔案，等等。
如果 EOGenerator 能夠在您決定模型相對穩定並且不再需要進行大量 EOModel 更改之後將兩個相關的 EO 類“合併”在一起，那就太好了。在專案生命週期的早期，當進行更多更改時，EOGenerator 非常有用。
如何完全不從 EOModeler 生成類檔案（假設您正在對 EOGenericRecord 進行子類化），並使 EO 類為空，除了您專門手動新增的自定義方法和訪問器之外？只要您使用 KVC 來獲取物件屬性，這應該可以正常工作。我有沒有看到這種方法的缺點？
只需手動新增/刪除/編輯屬性和關係。
您可以使用高階關係檢查器為關係新增參照完整性規則。
要新增參照完整性規則
- 選擇要新增規則的關係。
- 在關係檢查器中，點選高階關係檢查器圖示。
您可以使用高階關係檢查器中的欄位進一步指定關係。此檢查器中的選項將在以下部分中描述。
通常，當觸發故障時，只會從資料庫中獲取該物件（或對於多對多關係的陣列物件）。您可以透過將故障一起批處理來利用這種對資料庫的昂貴往返操作。您在“批處理大小”欄位中輸入的值表示應該與第一個故障一起觸發的相同關係的故障數量。有關批次故障的更多討論，請參閱企業物件框架參考中的 EODatabaseContext 類規範。
此欄位允許您指定關係是可選還是強制性。例如，您可以要求所有部門都有一個位置（強制性），但不要求每個員工都有一個經理（可選）。
此欄位允許您指定應應用於參與關係的實體的刪除規則。例如，您可能有一個部門有多個員工。當用戶嘗試刪除部門時，您可以
- 刪除部門並刪除員工對部門的任何反向引用（置空）。
- 刪除部門及其包含的所有員工（級聯）。
- 如果部門包含員工，則拒絕刪除（拒絕）。
- 允許刪除並且對目標物件不執行任何操作（不採取任何行動）。
不採取任何行動規則對於調整效能很有用。但是，您應該謹慎使用此刪除規則，因為它可能導致物件圖中出現懸空引用。有關更多資訊，請參閱企業物件框架參考中的 EOClassDescription 類規範。
“擁有目標”複選框允許您將源物件設定為擁有其目標物件。當源物件擁有其目標物件時，從源物件的關聯陣列中刪除目標物件也會導致其從資料庫中刪除（或者，您可以將其轉移到新的所有者）。這是因為所有權意味著被擁有的物件在沒有所有者的情況下無法存在，例如，行專案不能存在於採購訂單之外。
“傳播主鍵”複選框允許您指定源實體的主鍵應傳播到關係目標中新插入的物件。這通常用於所有權關係，其中被擁有的物件具有與源相同的 主鍵。例如，在“電影”資料庫中，TalentPhoto 實體具有與其所有者實體 Talent 相同的主鍵。
EOModeler 是一個非常古老的應用程式，自 NeXT 收購以來，蘋果對其關注不多。它有一些奇怪的行為，其中一些在 EOModeler 錯誤 頁面中有記錄。
有關與原型相關的 EOModeler 錯誤，請參閱 原型注意事項。