Архитектура для обработки как отмен, так и уведомлений

Question

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

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

Под Уведомления я имею в виду, что когда элемент создается / изменяется / удаляется, другие пользователи, которые заинтересованы в этом элементе, получат уведомление на месте (при следующей загрузке новой страницы) а также получит уведомление по электронной почте или SMS, если они попросят об этом.

Получить любую из этих функций очень просто: для отмены необходимо хранить информацию об отмене (в основном, старые версии измененных или удаленных элементов), в то время как уведомления так же просты, как вставка объекта уведомления в соответствующие таблицы и отправка электронной почты / SMS на муха.

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

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

Answer 1

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

• Пользователь может отменить операцию, нажав кнопку отмены или выполнивобратная операция (например, удаление его комментария).С точки зрения уведомлений, нет смысла рассматривать эти две ситуации по-разному.
• Уведомления для одного и того же объекта, которые происходят примерно в одно и то же время, должны, насколько это возможно, группироваться вместе: нет смысла отображать "A прокомментировал ваш пост "..." Z прокомментировал ваш пост "вместо" A, B ... и Z прокомментировал ваш пост ".Таким образом, уведомления о создании и удалении должны группироваться в соответствии с правилами группировки: если они достаточно близко друг к другу, они взаимно отменяют друг друга.
• Из-за возможности отмены никогда не отправляйте уведомления по электронной почте сразу.,Вместо этого подождите две минуты.Если операция отменяется, правила группы создания и удаления удаляют неотправленное уведомление, пока оно еще ожидает рассмотрения.Конечно, если пользователь в данный момент подключен, вы можете отображать уведомления в режиме реального времени, потому что в отличие от электронной почты, уведомления в режиме реального времени могут быть «возвращены».

Основываясь на этих принципах, ярешил создать два отдельных уровня поверх уровня доступа к данным:

• Набор семантически значимых операций, таких как «опубликовать новый комментарий» или «удалить комментарий», которыезатем отправляются уведомления.
• Определение пар операций отмены : аспект «отменить» «отправить новый комментарий» - это «удалить комментарий».

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

И наоборот, средства «отмены» просто вызывают код из семантического уровня, не требуя каких-либо знаний об отправляемых уведомлениях.

Очевидно, что все равно будет небольшое количество связипотому что иногда необходимо добавить семантическую операцию только потому, что она является «отменой» инверсии существующей операции.Например, можно отменить создание обсуждения, но нельзя удалить сообщение после его отправки (поскольку на него могут быть ответы).Таким образом, функция cancelDiscussion может существовать, когда deleteDiscussion недоступен.Я подозреваю, что такие ситуации достаточно редки, чтобы безопасно принять.

Answer 2

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

РЕДАКТИРОВАТЬ1: Переосмысливая это, я, вероятно, сразу же упорствую. В противном случае возникнет проблема с окончанием сеанса пользователя до истечения времени ожидания.

EDIT2: еще один вариант - использовать Windows Workflow Foundation 4 (WF4) и Компенсация . Настройте длительный постоянный рабочий процесс в качестве службы WCF. Рабочий процесс может быть просто действием получения WCF для его запуска, действием задержки и настраиваемым действием для отправки уведомлений; вам может даже не понадобиться CompensableActivity (если задержка не истекла и уведомление не было отправлено, отменить нечего). Каждый запрос уведомления вызывает WCF для запуска нового экземпляра рабочего процесса. Если пользователь отменяет, прервать экземпляр. (Может быть проще выполнить операцию Pick с задержкой и другой операцией получения WCF, которая отменяет уведомление при вызове.) Предупреждение: я не реализовал подобную систему.