Блог

Сначала я использую код Entity Framework, и пока у меня есть рабочий код, мне приходится выполнять строго ненужные вызовы базы данных для обработки следующего обновления.

У меня есть простой класс POCO для альбома с набором связанных тегов:

 public class Album
{
    public int Id { get; set; }
    public string Title { get; set; }
    public decimal Price { get; set; }
    public virtual IList<Tag> Tags { get; private set; }
}

public class Tag
{
    public int Id { get; set; }
    public string Name { get; set; }
}
  

Это обновляется с помощью формы MVC — с тегами, представленными рядом флажков.

Итак, когда я перехожу к своему методу обновления в репозитории, у меня есть класс album, заполненный списком тегов — теоретически все, что мне нужно для обновления.

Однако единственный способ, который я смог найти, чтобы обновить список тегов (удалить все, которые были установлены ранее, но теперь не отмечены, и добавить все, которые в настоящее время отмечены), — это извлечь исходный альбом из контекста и обновить его.

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

Вот мой код:

     public void Update(Album album)
    {
        var albumToUpdate = GetById(album.Id);   // - need to retrieve album with tags in order to update tags 
        albumToUpdate.Title = album.Title;
        albumToUpdate.Price = album.Price;
        albumToUpdate.Tags.Clear();

        if (album.Tags != null)
        {
            foreach (var tag in album.Tags)
            {
                var tagToAdd = context.Tags.Find(tag.Id);   // - need to retrieve full details of tag so doesn't fail validation
                albumToUpdate.AddTag(tagToAdd);
            }
        }     
    }
  

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

Ваш подход — перезагрузка entity graph из базы данных и объединение изменений вручную в него — на мой взгляд, правильный и лучший, что вы можете сделать.

Забудьте на мгновение, что вы используете Entity Framework. Что бы вы сделали, если бы вам пришлось писать инструкции SQL вручную? (EF — это оболочка вокруг генератора инструкций SQL.) Вы получите отправленный обратно граф объектов Album со списком Tags . Как бы вы теперь решили, какие теги вы должны написать для вставки, какие теги УДАЛИТЬ и для каких тегов оператор ОБНОВЛЕНИЯ? (Я предполагаю, что ваши отношения между Album и Tag являются «многие ко многим», поэтому вы записываете в таблицу соединений.) Если вы не знаете исходное состояние в базе данных, вы не можете решить. Существует ли отношение тегов в базе данных или нет? Вы должны запросить базу данных, чтобы найти ответ, независимо от того, используете ли вы EF или прямой SQL.

Я вижу только две альтернативы:

• Отслеживайте изменения сущности самостоятельно. Для вашего веб-приложения MVC это будет означать, что вы должны где-то сохранить исходное состояние с предыдущим запросом GET, например, в состоянии сеанса или в скрытых полях ввода на странице. С помощью запроса POST вы можете получить исходное состояние, построить и присоединить исходный граф и объединить в него изменения.

• Напишите хранимую процедуру, которая принимает коллекцию альбомов и тегов, и пусть SP выполняет работу по созданию соответствующих операторов SQL.

Первый способ сложен и имеет свои издержки в полезной нагрузке HTTP (скрытые поля ввода) или зависит от хрупкого состояния сеанса. А второе противоречит тому, почему вы используете ORM. Если у вас нет действительно серьезных проблем с производительностью или вы не являетесь мастером SQL, я бы не рассматривал хранимую процедуру.

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

Если вы не можете этого сделать, может быть менее запутанным не передавать один и тот же объект (альбом), а вместо этого использовать объект передачи данных (DTO) или другое сообщение только с нужными вам полями, а затем применить это к загруженному альбому.

Что касается основной проблемы, заключающейся в том, как избежать загрузки каждого тега, EF должен сделать это за вас, но я не знаю, что это делает. Например, NHibernate не будет загружать отложенный объект, если вы устанавливаете отношения только потому, что вы не затронули какие-либо свойства Tag , поэтому для его использования требуется только идентификатор. Надеюсь, EF делает то же самое, но, возможно, нет (я предполагаю, что вы его профилировали).

Если EF ведет себя не так, вы можете попробовать две вещи: во-первых, пока нет каскадного обновления тега, используйте скелетный с только идентификатором (то есть создайте объект самостоятельно и просто установите идентификатор); это не сработает, если EF cascade обновит тег. Во-вторых, вы могли бы реализовать свой собственный кэш для тегов и получать их из памяти.