Как моделировать приложение и иметь многопоточные потребности, гармонизировать с инкапсуляцией - PullRequest
0 голосов
/ 13 апреля 2011

Допустим, например, у меня есть приложение для заказа виджетов. Это позволяет клиентам делать заказ из каталога виджетов. Очевидными объектами выбора могут быть «Каталог» и «Заказы». Объект «Каталог» позволит мне просматривать, добавлять и удалять виджеты. Объект «Заказы» позволит мне создавать и обновлять заказы.

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

Распространенный способ справиться с этим сценарием - использовать шаблон наблюдателя. Другими словами, событие вызывается из «Каталога» при удалении детали. Затем посредник обрабатывает это событие и говорит «Заказы» удалить позиции с этим виджетом.

Плюсы: сохраняет герметизацию, слабое сцепление.

Минусы: не является ли удаление детали и обновление заказов единственной атомарной операцией? Эта техника будет нарушать это. Другими словами, если при обработке события произошла ошибка, деталь можно удалить без обновления каких-либо заказов.

Я предпочитаю минусы. Однако это может означать только то, что требуется другой объект - тот, который объединяет «Каталог» и «Заказы» и заставляет обе операции выполняться атомарно. Проблема заключается в том, что каждый объект выполняет блокировку объектов и транзакции базы данных, и я не вижу, как правильно извлечь их, т. Е. Теперь технически новый объект должен справиться с этой обязанностью, поскольку вы не можете блокировать объекты и выполнять транзакции дважды и при этом выполнять атомарную операцию. .

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

Спасибо.

1 Ответ

0 голосов
/ 13 апреля 2011

Это - ссылка, описывающая, как удаляются и обновляются / каскадируются различные типы отношений в GORM.Похоже, что описанная вами установка может быть смоделирована как несколько отношений 1: m или m: n.Ctrl + F для «каскадирования», и это должно пролить некоторый свет на то, как обрабатываются изменения между отношениями и как лучше всего моделировать отношения.Что касается ошибок, каскадирование также помогает позаботиться об этом, если вы предоставите правильные отношения «принадлежат».Если вы хотите удалить или изменить родительский объект, дочерние элементы также должны быть сначала удалены / обновлены.Если изменения, внесенные в дочерние элементы, не выполняются, исходный вызов не выполняется, и в базе данных не сохраняется никаких изменений.Когда документация ссылается на «сохранение» после внесения изменения, это относится к постоянным изменениям, которые, учитывая набор отношений, могут быть выполнены только при определенных обстоятельствах, таких как дочерние объекты, которые были сначала удалены каскадом.Извините, я не могу дать вам прямой ответ, так как я не уверен, пытаетесь ли вы изменить свой стиль модели или внедрить собственную реляционную модель, но, надеюсь, это вам немного поможет.Насколько я помню, GORM должен быть потокобезопасным.Перейдите на самый верх и прочитайте весь раздел «5. Реляционное сопоставление объектов (GORM)».Удачи!

...