.NET ORM 和持久的非属性状态

发布于 2024-10-24 09:05:17 字数 1790 浏览 7 评论 0原文

我刚刚开始使用 .NET ORM,甚至还没有在 Entity Framework 和 NHibernate 之间做出决定。但在这两种情况下,我都遇到了一个问题,因为他们似乎希望我以各种看起来不自然的方式设计我的课程。这是有关该主题的几个问题之一。


示例类:

public class Pledge // this is an entity BTW, not a value object
{
    private readonly int initialAmount;
    private bool hasBeenDoubledYet;

    public Pledge(int initialAmount)
    {
        this.initialAmount = initialAmount;
    }

    public int GetCurrentAmount()
    {
        return this.hasBeenDoubledYet ? this.initialAmount * 2 : this.initialAmount;
    }
    public void Double()
    {
        this.hasBeenDoubledYet = true;
    }
}

在这种情况下,持久化逻辑有点复杂。我们希望保留私有 initialAmounthasBeenDoubledYet 字段;重新实例化时,我们希望使用 initialAmount 调用构造函数,并在 hasBeenDoubledYet 字段为 true 时调用 Double()。这显然是我必须编写一些代码的事情。

另一方面,据我了解,典型的“ORM 友好”版本的代码可能最终看起来更像这样:

public class Pledge
{
    // These are properties for persistence reasons
    private int InitialAmount { get; set; }  // only set in the constructor or if you are an ORM
    private bool HasBeenDoubledYet { get; set; }

    private Pledge() { } // for persistence
    public Pledge(int initialAmount) { /* as before but with properties */ }

    public int GetCurrentAmount() { /* as before but with properties */ }
    public int Double() { /* as before but with properties */ }
}

我在 另一篇文章,但我想这个问题实际上是关于我如何可以让 ORM 处理私有字段而不是私有属性——可以在 EF 中完成吗?在NHibernate中?我们无法将字段标记为虚拟以用于代理目的...将使用它们的方法标记为虚拟就足够了吗?


这一切都感觉很老套:(。我希望这里有人能指出我错在哪里,无论是在我对他们能力的理解上,还是在我对领域建模和 ORM 的作用的思考上。

I am just getting started with .NET ORMs, to the point where I haven't even decided between Entity Framework and NHibernate. But in both cases, I'm running into a problem in that they seem to want me to design my classes in various ways that seem unnatural. This is one of several questions on the subject.


Example class:

public class Pledge // this is an entity BTW, not a value object
{
    private readonly int initialAmount;
    private bool hasBeenDoubledYet;

    public Pledge(int initialAmount)
    {
        this.initialAmount = initialAmount;
    }

    public int GetCurrentAmount()
    {
        return this.hasBeenDoubledYet ? this.initialAmount * 2 : this.initialAmount;
    }
    public void Double()
    {
        this.hasBeenDoubledYet = true;
    }
}

In this case the persistence logic is a bit complicated. We would want to persist the private initialAmount and hasBeenDoubledYet fields; when re-instantiating, we would want to call the constructor with initialAmount, and call Double() if the hasBeenDoubledYet field is true. This is obviously something I'd have to write some code for.

On the other hand, the typical "ORM friendly" version of the code would probably end up looking more like this, as far as I understand:

public class Pledge
{
    // These are properties for persistence reasons
    private int InitialAmount { get; set; }  // only set in the constructor or if you are an ORM
    private bool HasBeenDoubledYet { get; set; }

    private Pledge() { } // for persistence
    public Pledge(int initialAmount) { /* as before but with properties */ }

    public int GetCurrentAmount() { /* as before but with properties */ }
    public int Double() { /* as before but with properties */ }
}

I covered my reservations about default constructors and readonly fields etc. in another post, but I guess this question is really about how I could get ORMs to handle private fields instead of private properties---can it be done in EF? In NHibernate? We can't mark fields virtual for proxying purposes... would marking the methods that use them virtual suffice?


It all feels so hacky :(. I am hoping that someone here can point out where I am wrong, either in my grasp of their capabilities or in my thinking about domain modeling and the role of ORMs.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

网白 2024-10-31 09:05:17

我不了解 EF,但 NHibernate 需要您想要保留的虚拟和公共属性(正如您所说的代理原因)。

I don't know about EF, but NHibernate needs the properties you want to persist to be virtual and public (as you said for proxying reasons).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文