2009-03-01 110 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,并且这些想法应该被移植。)

这是一本模式书,但他提出了一些设计策略,主张将所有对象规则逻辑(“不变量”)都集中到集中域;然后他继续关于一些通常所了解的模式,并使像你这样的问题看起来更加易于理解。那么,如果不容易处理,至少在更长期内更易于管理。