EF4/WCF SaveChanges() Передовая практика

Почему вы делаете это с сущностями самоотслеживания? Что в этом было не так:

[OperationContract]
public User SaveUser(User entity)
{
    bool isDeleted = false;
    using (DatabaseEntities context = new DatabaseEntities())
    {
        isDeleted = entity.ChangeTracker.State == ObjectState.Deleted;
        context.Users.ApplyChanges(entity); // It deletes entities marked for deletion as well

        try
        {
            // no need to postpone accepting changes, they will not be accepted if exception happens
            context.SaveChanges(); 
        }
        catch (System.Data.OptimisticConcurrencyException)
        {
            context.Refresh(System.Data.Objects.RefreshMode.ClientWins, entity);
            context.SaveChanges();
        }
    }

    return isDeleted ? null : entity;
}

Если я не ошибаюсь, люди обычно не предоставляют свои объекты Entity Framework непосредственно в службе WCF. Entity Framework обычно рассматривается как уровень доступа к данным, а WCF — скорее интерфейсный уровень, поэтому они размещаются на разных уровнях.

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

Как правило, клиенты должны знать, «добавляют» они или «обновляют» объект, и лично я бы предпочел, чтобы это были две отдельные операции в интерфейсе службы. Кроме того, я бы определенно потребовал, чтобы они использовали отдельный метод для удаления объекта. Однако, если вам абсолютно необходимо общее «Сохранить», вы должны иметь возможность определить, является ли объект, который вам дали, «новым» или нет, на основе наличия (или отсутствия) значения первичного ключа.

Много кода можно поместить в универсальную утилиту. Например, предположим, что ваш шаблон T4 создает атрибуты для значений ключей ваших сущностей, вы можете автоматически определить, присутствуют ли значения ключей, и соответственно выполнить вставку/обновление. Кроме того, блок try SaveChanges catch retry, который вы используете, хотя, вероятно, и не нужен, можно легко поместить в простой служебный метод, чтобы сделать его более СУХИМ.