Почему так много программистов абсолютно ненавидят уровни распространенности объектов?

Распространенность - это простая методика предоставления свойств ACID объектной модели в памяти, основанной на двоичной сериализации и записи в журнал с опережением записи. Это работает так:

• Начните со снимка. Сериализуйте объектную модель и запишите ее в файл.
• Создайте файл журнала. Для каждого вызова в объектной модели сериализуйте вызов и его аргументы.
• Когда журнал становится слишком большим, вы закрываете, или в противном случае удобно выполнить контрольную точку: написать новый снимок и обрезать журнал.
• Чтобы выполнить откат или восстановление после сбоя или сбоя питания, загрузите последний снимок и повторите все вызовы, записанные в журнале.

Меры предосторожности, необходимые для выполнения этой работы:

• Не позволяйте ссылкам изменяемого объекта скрываться или входить в уровень распространенности. Вам нужна какая-то схема прокси или OID, как если бы вы делали RPC. (Это такая распространенная ошибка новичка, ее прозвали « проблема крещения ».)
• Вся логика, достижимая при вызове, должна быть полностью детерминированной и не должна выполнять значимые для бизнес-логики вызовы ввода-вывода или ОС. Запись в диагностический журнал, вероятно, в порядке, но получение системного времени или запуск асинхронного делегата, как правило, не так. Это делается для того, чтобы журнал воспроизводился одинаково, даже если он восстановлен на другом компьютере или в другое время. (Большая часть кода распространенности предоставляет альтернативный вызов времени для получения метки времени транзакции.)
• Писательский параллелизм вносит двусмысленность в интерпретацию журнала, поэтому он запрещен.

Это потому что ...

• люди разработали плохой вкус к ним после попытки использовать его в проекте, который не очень подходил ^* для него?
• Резкая пропаганда Клауса Вюстефельда оттеснила людей ?
• люди, которым нравится модель императивного программирования, не любят отделять ввод-вывод от вычислений , предпочитая вместо этого чередовать вычисления с входами-выходами и потоками?
• Уровни распространенности настолько концептуально просты и настолько тесно связаны с характеристиками структуры, в которой они обитают, что они обычно создаются специально для проекта, что делает их слишком чуждыми / нестандартными / рискованными?
• просто слишком сложно говорить прямо, что нужно быть осторожным, чтобы не делать?
• Головы новичков, кажется, просто взрываются, когда сталкиваются с чем-то, что не является тем же самым двухуровневым приложением на основе базы данных, которое они научились писать в школе? ;)

^* В всем наборе данных умещается в оперативной памяти , вам не нужен писатель параллелизм, и вам не нужно делать специальные запросы, отчеты или экспорт в хранилище данных. Извиняясь перед SQLite, распространенность - это улучшение файлов сохранения, а не замена Oracle.

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

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

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

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

Ответ на этот вопрос заключается в том, что, хотя теория проста, практика не так.

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

Любой монитор транзакций, такой как CICS, Tuxedo, Weblogic, Websphere, JBOSS или .NET, предоставит все эти средства в чистом и проверенном виде. И любая база данных обеспечит «достаточное» количество транзакций / постоянство для большинства приложений.

В основном это тот случай, когда колесо было изобретено и усовершенствовано очень давно.

Необходимые условия звучат немного обременительно для кодирования, особенно с большинством систем, которым не требуется соответствие ACID при работе в памяти. Сверхурочные звуки тоже звучат немного неприятно - там много отслеживания состояния.