2011-03-08 53 views
2

我們正在使用ORM /領域建模工具,該工具將允許我們跨MSSQL數據庫以「數據庫優先」方法生成的多個項目/程序集中生成多個相關領域模型。我們需要一些幫助來確定哪些工具可以滿足我們的需求。領域建模工具建議 - 跨項目關係和繼承

的要求是:

  1. 跨項目的關係

    • 我們的領域被分成許多模塊,併爲每個客戶端(我們給源代碼),我們不使用的所有模塊和所以我們想要「拔掉」他們不需要查看或訪問的所有邏輯。
    • 例如,我們希望將共享數據(主要是通用查找信息)存儲在它自己的常用程序集中。
    • 我們不需要模型之間的雙向關係(因爲這會導致循環引用)。只有關係的孩子結束纔會生成。
  2. 跨項目繼承

    • 與上述類似,我們希望能夠以抽象的共同功能集成到基類中的一個域模型和繼承他們。
    • 注意:域之間的繼承鏈接將受到限制,每個子域只有一個或兩個。
    • 注:這不應該的問題,而是我們使用「每個類型表」或「Class Table Inheritance」我們繼承我們的關係模型(DB)架構
  3. 生成的類是:

    1. 與DataContract /數據成員屬性標記
    2. 通知(通過INotifyPropertyChanged的實現方式)屬性改變
    3. 具有部分開*的PropertyName *改變()方法(例如按LINQ到SQL和實體框架生成的對象)
    4. (理想,但不是必需的)相關集合類型應實現INotifyCollectionChanged。

,以支持(或有變通方法來支持)任何ORM工具的任何反饋這些標準將不勝感激!

注:工具我們已經看過了(但這並不排除他們完全):

  • LightSpeed(可愛,但不輕易支持跨項目繼承)。
  • LLBLGen(複雜且包含所有內容,但使用AsSeparateProjects模式進行分組時似乎不支持跨模型關係,更不用說繼承了)。
  • 實體框架(我剛剛失去了...當設計師的故事splitting the domain across multiple models不是很好)。
+0

當選擇AsSeparateProjects時,LLBLGen Pro不支持通過組進行連接,因爲該模型會導致多個vs.net項目。如果我們允許跨越組邊界的連接(如您所請求的那樣),那麼vs.net項目最終會相互引用,這是不可能的,因爲這會導致循環引用。 – 2012-05-18 07:58:34

回答

1

這絕對需要小概念驗證項目,因爲您的要求不是在EF有關論文中通常描述的內容。

對於1.和2.通過這些文章(part 1,part 2),並嘗試做出簡單的解決方案,這將證明你能夠在多個EDMX中使用關係和繼承。

最後一點將由自定義T4模板來滿足從EDMX生成類 - 從POCO模板開始並改變其生成功能。

+0

對於這一個記錄:經過大量的概念驗證工作,我們使用實體框架。我們正在使用類似於EdmGen2的自建命令行工具來完成上面鏈接的第2部分中提到的所有CSDL內容,同時仍然使用設計器。這一切都很好,現在輕鬆地掛在一起!我希望很快就能發佈它 - 所以請留意這個空間。 – Reddog 2011-04-07 20:45:23

1

雖然它聽起來像是你要求的相反,但我可能會看EF Code First。因爲它都建立在POCO,DbSets和DbContext類之上,所以你可以很容易地獲得繼承。

在普通程序集中有共享模型和抽象DbContext。在客戶特定的程序集中有特定的模型和最終的DbContext。

在WinForms前面,有example code here關於如何使集合可觀察。你需要自己照顧INotifyPropertyChanged,但這很容易。

對於您來說EF Code First的缺點是沒有辦法只生成所有的類。話雖如此,但他們足夠簡單,可以在編寫應用程序的其餘部分時按照需要編寫它們。任何形式的通用自動化工具都無法確定哪些模型和屬性與客戶特定的屬性相同。

+0

我對EF Code First的直接反應是POCO非常簡單 - 我認爲這一點真的很重要......實際上,我們希望支持POCO之上的衆多方面,而無需手工編寫所有內容。例如,INotifyPropertyChanged支持和部分「On ... Changed」方法。實際情況是,關鍵領域行爲的大部分都是在On ..Changed中執行的,屬性改變了相關實體的反應,以及屬性驗證。也就是說,我們通常添加到生成模型頂部的部分類的所有好東西(INotifyPropertyChanged實現除外)。 – Reddog 2011-03-08 21:52:14