Блог

Некоторое время я думал о том, как обращаться с объектами, которым назначены идентификаторы базой данных.

Типичный объект, представляющий объект table, может выглядеть следующим образом:

 public class Test
{
    public int Id { get; private set; }
    public string Something { get; set; }
}
  

Предположим, мы хотели бы использовать этот объект для вставки, извлечения и обновления объектов в базе данных. Что касается извлечения и обновления, у нас нет проблем, поскольку поле Id всегда имеет значение.

Однако, если мы хотим вставить новый объект типа Test в базу данных, поле Id все равно должно иметь значение. Мы могли бы просто использовать «0», поскольку его вряд ли можно использовать в качестве ключа базы данных, но на самом деле это не очень хороший дизайн.

Аналогично, если мы изменим ситуацию и сделаем свойство Id равным нулю, мы могли бы использовать null для объектов, которым база данных еще не присвоила идентификатор. Однако теперь объект, извлеченный из базы данных, может не иметь идентификатора (что разрешено дизайном класса, но не дизайном базы данных)

Есть хорошие идеи о том, как создать хороший дизайн для этой проблемы?

Если вы рассматриваете id это как способ идентификации / предоставления уникальности объекту в вашем приложении, это должно быть обработано database (если, конечно, у вас есть другие способы присвоения идентификаторов объектам).

Если это не так (например, это свойство объекта, определяемое бизнес-потребностями) — является ли 0 допустимым / хорошим значением дизайна или нет, зависит исключительно от этих бизнес-потребностей. Является 0 допустимым значением, скажем, с точки зрения конечного пользователя?

Вы всегда можете перенести свойства вашего объекта в отдельный класс, если чувствуете, что наличие объектов без ids set в вашем приложении проблематично. Вы будете использовать такой класс по существу только для переноса параметров для еще не созданного объекта (процесс создания завершается вставкой в базу данных). Как только объект будет вставлен, идентификатор присвоен и прочее — вы сможете работать с вашим обычным объектом. Скажет ли ваш пользователь «О, щелчок! Что это?» или «Ок .. Я знаю, что делать». однажды к id = 0 обратился?

Редактировать

Этот вопрос (или, скорее, мой ответ о переносе параметров) напомнил мне о факте, который однажды меня удивил. Когда рождается ребенок, он не существует в системе до тех пор, пока его родители официально не зарегистрируют его и ему не присвоят личный идентификационный номер. Итак, технически, without id — child не существует (по крайней мере, с системной точки зрения), даже если все знают, что она родилась и все такое. То же самое с базой данных / вашим приложением — объект без id (тот, который база данных не может идентифицировать) не существует — это просто набор параметров. Немного странно, но я надеюсь, что моя точка зрения ясна 🙂

Нет ничего плохого в разработке класса таким образом, чтобы идентификатор 0 указывал, что объект еще не был сериализован. В прошлом я создавал системы, которые успешно использовали этот подход. Просто убедитесь, что эта семантика четко определена в вашем API и что это значение соблюдается во всем коде.

Одной из ловушек, которой следует остерегаться, является использование идентификатора для определения отношения равенства (например, для генерации хэш-кодов для словаря). Это должно быть сделано только для ненулевых идентификаторов. Для проверки равенства с двумя нулевыми идентификаторами может использоваться ссылочное равенство.

Однако, поскольку идентификатор не сохраненных объектов может измениться в какой-то момент в будущем, очень важно, чтобы такие объекты никогда не сохранялись в словаре. Или, по крайней мере, такие элементы должны быть удалены из любых словарей перед сохранением, а затем восстановлены впоследствии с использованием нового идентификатора.

С этой единственной оговоркой этот дизайн должен работать нормально.

 public class Test : IEquatable<Test>
{ 
    /// <summary>
    /// The unique identifier for this Test entity, or zero if this
    /// Test entity has not yet been serialized to the database.
    /// </summary>
    public int Id { get; private set; } 

    public string Something { get; set; }

    public override bool Equals(object obj)
    {
        return Equals(obj as Test);
    }

    public bool Equals(Test other)
    {
        if (other == null)
            return false;
        // Distinct entities may exist with the Id value of zero.
        if (Id == 0)
            return object.ReferenceEquals(this, other);
        return Id == other.Id;
    }

    /// <summary>
    /// Gets a hash code for this Test entity. Warning: an instance with
    /// an Id of zero will change its identity when saved to the DB. Use with care.
    /// </summary>
    /// <returns>The hash code.</returns>
    public override int GetHashCode()
    {
        return Id;
    }
} 
  

Итак, у вас есть класс, который содержит идентификатор таблицы базы данных в виде поля, поэтому в случае извлечения / удаления и обновления идентификатор вашей сущности совпадает с идентификатором записи базы данных. В случае вставки вы могли бы получить значение identify только что вставленной записи и обновить свой объект этим значением. Таким образом, у вас могли бы быть отдельные процедуры хранения для вставки / обновления / извлечения и удаления. SP вставки может вернуть вам идентификатор записи, только что вставленной как out parameter . Надеюсь, я отвечу на ваш вопрос.