.NET ORM и сохраняющееся неимущественное состояние - PullRequest
Новая
       37

.NET ORM и сохраняющееся неимущественное состояние

0 голосов
/ 19 марта 2011

Я только начинаю работать с .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;
    }
}

В этом случае логика сохранения немного сложна. Мы хотели бы сохранить частные поля initialAmount и hasBeenDoubledYet; при повторном создании мы хотели бы вызвать конструктор с initialAmount и вызвать Double(), если поле hasBeenDoubledYet равно true. Это, очевидно, то, что я должен написать код для.

С другой стороны, типичная "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? Мы не можем пометить поля virtual для целей прокси ... достаточно ли маркировки методов, которые их используют virtual?

Все это кажется таким хакерским :(. Я надеюсь, что кто-то здесь может указать, где я не прав, либо в моём понимании их возможностей, либо в моих мыслях о моделировании предметной области и роли ORM.

1 Ответ

0 голосов
/ 19 марта 2011

Я не знаю об EF, но NHibernate требует, чтобы свойства, которые вы хотите сохранить, были виртуальными и общедоступными (как вы сказали по причинам прокси).

...