Что я могу сделать для предотвращения конфликтов записи записи на веб-сайте стиля Wiki?
Наследование может быть представлено в базе данных по-разному, и существуют некоторые стратегии в зависимости от того, какой ORM вы используете. В конце концов, используя одну из стратегий , вы можете основать свой репозиторий на базовом классе и позволить ORM выступать в качестве прокси для разрешения нужного вам экземпляра или попытаться воссоздать себя в уровень хранилища, основанный на поле дискриминатора, нужные вам экземпляры
Receipt
ID
ReceiptNumber
CustomerNumber
CustomerEmail
CustomerOption
InternalNumber
InternalEmail
InternalOption
DISCRIMINATOR_FIELD
(большинство ORM делают этот перевод за вас), но для того, чтобы вы поняли идею, вы можете оставить только один хранилище для обработки всех классов как квитанции и сохранения иерархии в том виде, в каком она у вас есть.
открытый интерфейс IReceiptRepository {public Receipt Get (int id); Публичная квитанция Добавить (квитанция квитанции); }
public CustomerReceiptRepository : IReceiptRepository {
public Receipt Get(int id) {
var rec = DbContext.Table.Receipt.FirstOrDefault(r => r.id = id);
if(rec.DiscriminatorField == 1) //CustomerReceipt
{
return new CustomerReceipt
{
ID = ...
ReceiptNumber = ...
CustomerNumber = ...
CustomerEmail = ...
CustomerOption = ...
}
}
//all other cases are InternalReceipts
return new InternalReceipt
{
ID = ...
ReceiptNumber = ...
InternalNumber = ...
InternalEmail = ...
InternalOption = ...
}
}
}
То же самое для метода Add, просто заполните только те поля, которые вам нужны для этого объекта. В этой композиции все основано на поле дискриминатора. Я не предлагаю , чтобы вы реализовали свое решение таким образом, но при этом вы все равно получаете в своей ViewModel общую квитанцию. Я предлагаю вам прочитать больше об ORM, который вы используете, и о том, как вы можете представить там наследование (может быть, вы сначала используете базу данных, а не код, и вам придется обрабатывать вещи вручную, потому что база данных не была разработана таким образом. и вам нужно использовать подход, аналогичный тому, что я предложил. Но если у вас есть возможность создать свои классы POCO и создать базу данных, определенно стоит взглянуть на то, как они реализуют наследование.
Здесь Я прилагаю ссылку о том, как эта проблема решается в EntityFramework 6
Стратегия наследования в Entity Framework 6
Надеюсь, это поможет
8 ответов
Помните номер версии (или идентификатор) последнего изменения. Затем считайте запись прежде, чем записать это и сравните, если эта версия является все еще тем же.
В случае конфликта сообщают пользователю, который пытался записать запись, которая была изменена тем временем. Поддерживайте его с различным.
Большинство wikis делает это этот путь. MediaWiki, Usemod, и т.д.
Трехстороннее слияние: первая вещь указать состоит в том, что большинство параллельных редактирований, особенно на более длинных документах, к различным разделам текста. В результате путем замечания, который получили Пользователи пересмотра A и B, мы можем сделать трехстороннее слияние, как детализировано Bill Ritcher из Guiffy Software. Трехстороннее слияние может определить, где редактирования были сделаны из оригинала, и если они не сталкиваются, это может тихо объединить оба редактирования в новую статью. Идеально, в этой точке выполняют слияние и показывают Пользователю B новый документ так, чтобы она могла принять решение далее пересмотреть его.
Разрешение коллизий: Это оставляет Вас со сценарием, когда оба редактора отредактировали тот же раздел. В этом случае объедините все остальное и предложите текст этих трех версий Пользователю B - то есть, включайте оригинал - или с версией Пользователя A в текстовом поле или с Пользователь B. Тот выбор зависит от того, думаете ли Вы, что значение по умолчанию должно быть должно принять последнее (пользователь просто нажимает Save для сохранения их версии), или вынудите редактора отредактировать дважды для вкладывания их изменений (они должны повторно применить свои изменения в версии редактора A раздела).
Используя трехстороннее слияние как это избегает локаутов, которые очень трудно обработать хорошо в сети (сколько времени Вы позволяете им иметь блокировку?), и ухудшение 'Вы могли бы хотеть посмотреть снова' сценарий, который только работает хорошо на ответы стиля форума. Это также сохраняет постответить стиль сети.
Если Вы хотите к Ajax это немного, динамично версии Пользователя слияния с 3 путями A в версию Пользователя B, в то время как они редактируют его, и уведомляют их. Теперь, когда было бы впечатляющим.
В Mediawiki сервер принимает первое изменение, и затем когда второе редактирование сохраняется, страница конфликтов подходит, и затем второй человек объединяет два изменения вместе. Посмотрите Википедию:Помощь: Конфликты редактирования
В Gmail, если мы пишем ответ на почту и кто-то еще отправляет ответ, в то время как мы все еще вводим его, всплывающее окно кажется указывающим, что существует новое обновление, и само обновление появляется как другое сообщение без перезагрузки страницы. Этот подход удовлетворил бы Вашим потребностям и если можно использовать Ajax для показа точного сообщения со ссылкой на разность того, что было просто обновлено, в то время как Пользователь B все еще занят, вводя его запись, которая была бы большой.
Используя блокировку механизм, вероятно, будет самым легким реализовать. Каждой статье можно было связать поле блокировки с ним и время блокировки. Если бы время блокировки превысило некоторое установленное значение, то Вы полагали бы, что блокировка недопустима и удаляет его при проверке статьи для редактирования. Вы могли также отслеживать открытые блокировки и удалить их на сессии близко. Необходимо было бы также реализовать некоторое управление совместным выполнением в базе данных (автоматически сгенерированные метки времени, возможно) так, чтобы Вы могли удостовериться, что регистрируетесь в обновлении версии, которую Вы проверили, на всякий случай два человека смогли отредактировать статью одновременно. Только тот с правильной версией смог бы, успешно регистрируются в редактировании.
Вы могли бы также смочь найти механизм различия, который Вы могли просто использовать для построения различий, хотя отображение их в редакторе Wiki может быть проблематичным - на самом деле отображение различий, вероятно, более трудно, чем построение различного. Вы полагались бы на систему управления версиями для обнаружения, когда необходимо было отклонить редактирование и выполнить различное.
Как Ravi (и другие) сказали, Вы могли использовать подход Ajax и сообщить пользователю, когда другое изменение происходит. Когда редактирование отправлено, просто укажите на текстовые различия и освободите вторую пользовательскую работу, как объединить эти две версии.
Однако я хотел бы прибавить с чем-то новым, которое Вы могли попробовать в дополнение к этому: Откройте диалоговое окно чата между редакторами, в то время как они делают свои редактирования. Вы могли использовать что-то как встроенный Gabbly для этого, например.
Лучшее разрешение конфликтов является прямым диалоговым окном, говорю я.
Ваша проблема (потерянное обновление) решена лучше всего с помощью Управления Оптимистичным параллелизмом.
Одна реализация должна добавить столбец версии в каждом доступном для редактирования объекте системы. На пользователе редактируют Вас, загружают строку и отображают форму HTML на пользователе. Скрытое поле дает версию, скажем, 3. Запрос на обновление должен посмотреть что-то как:
update articles set ..., version=4 where id=14 and version=3;
Если возвращенные строки 0 затем, кто-то уже обновил статью 14. Все, что необходимо сделать затем, - то, как справиться с ситуацией. Некоторые общие решения:
- последние победы фиксации
- первые победы фиксации
- слияние, конфликтующее обновления
- позвольте пользователю решить
Вместо версии постепенного увеличения, международной/длинной, можно использовать метку времени, но она не предлагается потому что:
получение текущего времени от JVM не обязательно безопасно в кластерной среде, где узлы не могут быть синхронизируемым временем.
(кавычка от персистентности Java с в спящем режиме),
Еще некоторая информация в быть в спящем режиме документации.
В моем офисе у нас есть политика, что все таблицы данных содержат 4 поля:
- CreatedBy
- CreatedDate
- LastUpdateBy
- LastUpdateDate
Тем путем там является хороший журнал аудита на том, кто сделал что к записям по крайней мере последний раз.
Но самое главное, становится достаточно легко выдержать сравнение, LastUpdateDate текущей или отредактированной записи на экране (требует, чтобы Вы сохранили его на странице, в cookie, безотносительно, со значением в базе данных. Если значения не соответствуют, можно решить, что сделать оттуда.