Устранит ли использование транзакции необходимость использования вторичных контекстов данных для попытки вставки/обновления/удаления sql?

Итак, у меня есть список билетов ИТ/разработчика, хранящихся в базе данных через Linq-To-Sql. Попытки сохранения выполняются только по запросу пользователя или если они говорят сохранить при закрытии. Меня беспокоило то, что пользователь вносит изменения в 2 или более билетов, не сохраняя их между ними.

По какой-то причине, если база данных отклоняет изменение на один, не дает мне очень много информации о том, какой элемент или какое поле в какой заявке имеет проблему, поэтому я могу связать это с предоставлением индикатора пользователю. Теперь я не могу сохранить хорошие данные по отредактированным ими записям, потому что одно изменение застряло в очереди, и теперь SubmitChanges больше не работает.

Я построил систему буферизации, в которой каждый билет оборачивается в другой класс, чтобы изменения сохранялись в буфере, а не непосредственно в объекте linq to sql, где для каждого измененного билета:

  • Я мог бы создать новый экземпляр dataContext
  • попытаться сохранить изменения для отдельной строки
  • затем сообщайте пользователю о каждой неудачной попытке.

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

Мой коллега только что предложил мне попробовать транзакции. Я бы предпочел не разбирать то, что я создал для проверки транзакционного подхода.

  • Будут ли транзакции корректно сбрасывать все изменения элемента или все элементы, которые SaveChanges попытается сохранить? после этого я ожидал бы, что hasChanges будет пустым, а SaveChanges ничего не сделает.
  • Есть ли лучший способ одновременно отправлять изменения отдельных строк в linq-to-sql?
  • Я что-то упустил в исключениях SaveChanges, которые действительно помогли бы мне узнать, в какой строке и в каком поле в этой строке возникла проблема?

Возможно, я не должен позволять (из-за linq-to-sql или в реальном мире не нужна возможность вносить изменения в несколько модулей, не решая, сохранять или нет) пользователю оставлять заявку, пока они не решат, хотят ли они сохранять изменения в нем или нет?


transactions linq-to-sql ticket-system
person Maslow    schedule 10.09.2009    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я перекатил свой собственный класс буферизации, это немного грязно, но работает точно, сохраняя по одной записи за раз.

Это родительский класс для моих бизнес-объектов, которые обертывают сущность linq.

public class BufferedLinqChange
{
    LqGpsDataContext _dataContext;

    internal BufferedLinqChange(LqGpsDataContext dataContext)
    {
        _dataContext = dataContext;
    }

    protected void SetBufferedProperty<T>(string key,Action linqAction
        ,bool linqEqualsValue,Action bufferAction)
    {
        if (linqEqualsValue)
        {
            if (Changes.ContainsKey(key))
                Changes.Remove(key);
        }
        else
        Changes.InsertOrUpdate(key, linqAction); bufferAction();
    }

    protected Dictionary<String, Action> Changes = new Dictionary<string, Action>();

    public int ChangeCount { get { return Changes != null ? Changes.Count : 0; } }
    public bool hasChanges { get { return Changes != null ? Changes.Count > 0 : false; } }

    public void SubmitChanges()
    {
        _dataContext.SubmitChanges();
        if (ChangeCount > 0)
        {
            Changes.ForEach((item) => item.Value.Invoke());
            _dataContext.SubmitChanges();
        }
    }
    public void CancelChanges()
    {
        if (Changes != null)
            Changes.Clear();
    }
}

Вот пример одного из свойств:

#region assetTag


    String _AssetTag;
    public const String STR_assetTag = "assetTag";
    public String assetTag
    {
        get { return (Changes.ContainsKey(STR_assetTag) ? _AssetTag : Asset.assetTag); }
        set
        {
            SetBufferedProperty<String>(STR_assetTag
                , () => Asset.assetTag = value, Asset.assetTag == value, () => _AssetTag = value);
        }
    }
    #endregion
person Maslow    schedule 14.09.2009
comment
Я разместил в блоге гораздо больше кода, который использовал, по адресу imaginarydevelopment.blogspot.com/2009/09/ - person Maslow; 15.09.2009