任何.NET ORM都"正确"使用构造函数吗?

Har*_*lby 7 .net orm

这在概念上与我的问题在这里.但是,我一直在玩NHibernate,并意识到我的问题的真正核心是什么.

在经典的OO设计中,为了正确地封装数据,将值传递给存储在数据成员(字段)中的对象构造函数是一种常见模式.应的那些值被改变暴露只访问器(只读属性).允许更改的那些具有访问器和更改器(读写属性).在我看来,正确的 O/RM应该遵守这些约定,并在创建对象时使用可用的构造函数.依赖于读写属性,反射或其他,hackish(恕我直言)方法似乎......错了.

是否有一个.NET O/RM解决方案可以做到这一点?

编辑

为了解决Praveen的观点,我知道有些项目具有用于选择构造函数的"默认"算法 - 例如,StructureMap总是使用具有最多参数的构造函数,除非您使用自定义属性标记构造函数.我可以看到这是处理这种情况的有效方法.除了 ORM 之外,使用IoC容器可能会提供我需要的那种解决方案 - 尽管在我看来,这虽然不是本身就很糟糕,但是使用ORM是一个不必要的额外步骤.

Har*_*lby 1

天哪,我想我已经做到了!

感谢大家的意见,但我必须回答我自己的问题。我只是花了一个小时左右的时间挖掘PoEAA 目录,思考 OO 原则,并将其与对 C# 语言和 .NET 框架的深入思考结合起来。

我想出的答案,即我无法使用构造函数正确解决的一个需求,最终与构造函数本身无关。这是延迟加载

基本上,如果不在域类中实现延迟加载(持久性无知和灵活性的主要禁忌),就无法在不子类化域类的情况下做到这一点。这种子类化是 NHibernate 需要虚拟属性的原因。

我仍然认为使用构造函数而不是反射或其他一些方法来填充父类的字段会更好(至少对于非集合......延迟加载确实有它的位置),但我绝对看到哪里没有-arg 构造函数有其一席之地。