Передача конфликтов параллелизма на прикладной уровень

Существует ли альтернатива использованию исключений при передаче конфликтов параллелизма на прикладной уровень, которая также соблюдает принцип Разделение команд и запросов, или исключения — лучший механизм, который у нас есть (в языках, поддерживающих исключения)?

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

// 'data' is just a placeholder for multiple parameters, including something
// that contains row version information
void Customer.UpdateInformation(object data);

Мне нужно иметь возможность сообщить пользователям веб-приложения, когда кто-то другой обновил данные, над которыми они работают.

Я бы предпочел не возвращать значение из методов, которые изменяют данные. Поэтому в прошлом я выдавал исключения (похожие на API адаптера данных .NET, который выдавал ошибку DBConcurrencyException при обнаружении конфликтов), но конфликты параллелизма, по здравому смыслу, не являются исключительными. Это факт жизни: предсказуемая, ожидаемая часть рабочего процесса приложения. Квалифицируются ли они как экзогенные исключения в исследовании Эрика Липперта? таксономия?


.net concurrency data-access-layer command-query-separation
person Jeff Sternal    schedule 01.06.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person Steven    schedule 01.06.2010