2009-03-01 70 views
2

我認爲我在構建業務模型時花費最多時間的是驗證業務實體並確保實體對象及其關係保持良好的完整性。對於一個好的實體/價值對象框架,我的夢想將幫助我創建可重用的實體/值對象,並輕鬆創建關係的約束和規則,就像在db中一樣,但是因爲我覺得這確實是它們屬於模型的業務規則,應該是完全獨立於數據庫。具有DbC支持的業務實體/值對象框架

應該很容易定義Person對象的Name屬性應該是必需的,並且Email屬性應該是必需的並且匹配某個正則表達式,並且這些規則應該易於重複使用f.ex.在我的網絡應用中驗證輸入。

我對LINQ有絕對大部分的經驗,儘管它對於使用LINQ有很大的幫助,但由於它不支持值對象和其他屬性而受到限制。我的問題是Entity框架或NHibernate會更適合還是有其他技術更適合我的需求?

回答

0

有一個small book I read last year by Steve Sanderson himself向我簡要介紹了DDD的概念。儘管本書是以ASP.NET MVC爲預覽版的,但他確實將MVC中的「M」作爲一個真正的純粹的領域模型 - 使用了近1/2的關於建模方法的書(我非常喜歡)。他接觸到的一件事就是在聚合根的上下文中使用Value Objects(顯然)。但是,他還展示瞭如何使用Linq來表示實體以及價值對象。

問題是,他指出了Linq的限制,即它必須在每個對象上都有一個標識,包括值對象。他承認它打破了純領域模型的方法;但是,這是使它與Linq-to-SQL一起工作的唯一方法。

他的解決方法是給你的價值對象一個身份;但是,請將該身份內部化,以免暴露在模型之外。這將允許您在存儲庫中使用Linq鏈接和共享您的對象;而不會將它暴露給客戶層 - 因此,它就好比它們是Value Objects的獨佔。

我相信實體框架遭受同樣的要求。

C#示例如下。

public class MyEntity 
{ 
    [Column(IsPrimaryKey = true 
    , IsDbGenerated = true 
    , AutoSync = AutoSync.OnInsert)] 
    public int EntityID { get; set; } 

    [Column(CanBeNull = false)] 
    public string EntityProperty 
    { 
    get 
    { 
     // insert business rules here, if need be 
    } 
    set; 
    } 
} 

public class MyValueObjectForMyEntity 
{ 
    // make your identity internal 
    [Column(IsPrimaryKey = true 
    , IsDbGenerated = true 
    , AutoSync = AutoSync.OnInsert)] 
    internal int ValueObjectID { get; set; } 

    // everything else public 
    [Column(CanBeNull = false)] 
    public string MyProperty { get; set; } 
} 
0

即使它出現在世界的.Net一側,我也強烈推薦Eric Evans的書「Domain Driven Design」。 (實際上有比Java更多的UML,並且這些想法應該被移植。)

這是一本模式書,但他提出了一些設計策略,主張將所有對象規則邏輯(「不變量」)都集中到集中域;然後他繼續關於一些通常所瞭解的模式,並使像你這樣的問題看起來更加易於理解。那麼,如果不容易處理,至少在更長期內更易於管理。