Entity Framework 4 — где разместить логику ApplyCurrentValues?

Разобрался - это было непросто, поэтому постараюсь объяснить, как смогу. (для тех, кому не все равно)

Соответствующий код контроллера:

// _userContentService is IUserContentService
_userContentService.Update(review);

Итак, мой контроллер вызывает метод с именем Update для IUserContentService, проходя через строго типизированный объект Review.

Соответствующий код службы пользовательского контента

public void Update(Post post)
{
   // _userContentRepository is IPostRepository
   _userContentRepository.UpdateModel(post);
}

Итак, моя служба вызывает метод с именем UpdateModel для IPostRepository, проходя через строго типизированный объект Review.

Теперь, вот сложная часть.

На самом деле у меня нет конкретных репозиториев. У меня есть общий репозиторий под названием GenericRepository<T> : IRepository<T>, который обрабатывает все различные репозитории.

Поэтому, когда что-то запрашивает IPostRepository (что делала моя служба), DI давал ему GenericRepository<Post>.

Но теперь я ставлю ему PostRepository:

public class PostRepository : GenericRepository<Post>, IPostRepository
{
   public void UpdateModel(Post post)
   {
      var originalPost = CurrentEntitySet.SingleOrDefault(p => p.PostId == post.PostId);
      Context.ApplyCurrentValues(GetEntityName<Post>(), post);
   }
}

А поскольку класс наследуется от GenericRepository, он наследует всю основную логику репозитория (найти, добавить и т. д.).

Сначала я попытался поместить этот код UpdateModel в сам класс GenericRepository (и тогда мне не понадобился бы этот конкретный репозиторий), но проблема заключается в логике извлечение существующего объекта основано на определенном ключе объекта, о котором GenericRepository<T> не знает.

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

ИЗМЕНИТЬ

Этот «метод заглушки» также работает:

public void UpdateModel(Post post)
{
   var stub = new Review {PostId = post.PostId};
   CurrentEntitySet.Attach(stub);
   Context.ApplyCurrentValues(GetEntityName<Post>(), post);
}

Но проблема в том, что Post является абстрактным, я не могу создавать экземпляры и поэтому должен проверять тип Post и создавать заглушки для каждого отдельного производного типа. Не совсем вариант.

ИЗМЕНИТЬ 2 (ПОСЛЕДНИЙ РАЗ)

Хорошо, у вас есть «метод заглушки», работающий с абстрактными классами, так что теперь проблема параллелизма решена.

Я добавил параметр универсального типа в свой метод UpdateModel и специальный параметр ограничение new().

Реализация:

public void UpdateModel<T>(T post) where T : Post, new()
{
   var stub = new T { PostId = post.PostId };
   CurrentEntitySet.Attach(stub);
   Context.ApplyCurrentValues(GetEntityName<Post>, post);
}

Интерфейс:

void UpdateModel<T>(T post) where T : Post, new();

Это избавляет меня от необходимости определять тип T вручную, предотвращает проблемы параллелизма, а также предотвращает дополнительное обращение к БД.

Довольно заводной.

ИЗМЕНИТЬ 3 (я думал, что последний раз был последним)

Приведенный выше «метод заглушки» работает, но если я извлеку объект заранее, он выдаст исключение, указывающее, что сущность с этим ключом уже существует в OSM.

Кто-нибудь может подсказать, как с этим справиться?

РЕДАКТИРОВАТЬ 4 (Хорошо, вот оно!)

Я нашел решение благодаря этому ответу SO: to-a-data-context-in-ent/1716109#1716109">Можно ли проверить, присоединен ли объект к контексту данных в Entity Framework?

Я пытался «проверить, прикреплен ли объект», используя следующий код:

ObjectStateEntry entry;
CurrentContext.ObjectStateManager.TryGetObjectStateEntry(entity, out entry);

Но он всегда возвращал null, даже когда я исследовал OSM, я мог видеть там свою сущность с тем же ключом.

Но этот код работает:

CurrentContext.ObjectStateManager.TryGetObjectStateEntry(CurrentContext.CreateEntityKey(CurrentContext.GetEntityName<T>(), entity), out entry)

Может быть, из-за того, что я использую Pure POCO, у OSM возникли проблемы с определением ключа объекта, кто знает.

Да, и еще одну вещь, которую я добавил — чтобы мне не нужно было добавлять отдельный репозиторий для каждой сущности, я создал атрибут с именем «[EntityKey]» (атрибут общедоступного свойства).

Все POCO должны иметь 1 общедоступное свойство, украшенное этим атрибутом, иначе я создам исключение в своем модуле репозитория.

Итак, мой общий репозиторий затем ищет это свойство, чтобы создать/настроить заглушку.

Да, он использует отражение, но это умное отражение (на основе атрибутов), и я уже использую отражение для плюрализации имен наборов сущностей из T.

В любом случае, проблема решена - теперь все работает нормально!