Рекомендации по использованию контейнеров

Question

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

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

Answer 1

Я не считаю, что можно использовать один и тот же экземпляр контейнера в нескольких таблицах с разным фильтром - (не уверен на 100%, но это очень сильный инстинкт)

С этим в виду, я бы склонно делать что-то вроде

1. Создать/использовать какое-то автобус событий вещать/подписаться сообщения о том, «Я обновил таблицу XYZ»
2. Создать расширение SQLContainer переопределяет #fireContentsChange вещать, когда таблица обновляется, а также реагирует на eventbus, вызывая #fireContentsChange (если sourve сообщения автобуса событие не это)

Там, наверное, более сложный/лучший способ сделать это с одним общим Container.ItemSetChangeEvent, но это сложно думать, что это через при вводе текста в текстовом браузере поле.

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

Answer 2

Обычно у вас разные контейнеры для разных экземпляров таблиц. Хотя в некоторых случаях вам может понадобиться использовать один и тот же экземпляр контейнера между различными компонентами. Это вполне возможно и приемлемо, если вы понимаете последствия: Фильтрация и сортировка выполняются на уровне контейнера, что означает, что если вы примените фильтр в контейнере в одном представлении, а затем перейдите к другому представлению, контейнер будет там тоже фильтруется. Непонимание этого может привести к «странным ошибкам» и множеству WTF.

Преимущества совместного использования одного и того же экземпляра контейнера связаны с минимизацией объема памяти вашего приложения - чем больше контейнеров у вас есть, тем больше памяти вы будете потреблять. Обратите внимание, что и таблица, и SQLContainer - это ленивая загрузка - это означает, что таблица не будет отображать больше строк в браузере, чем то, что необходимо для заполнения области таблицы (+ некоторый буфер), SQLContainer не будет получать больше строк, чем то, что необходимый для таблицы -> ваш контейнер фактически не будет содержать в памяти более нескольких десятков элементов (* ваш пробег может отличаться).

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

Итак, как насчет этой лучшей практики? Лично я бы начал с нескольких экземпляров контейнера (по одному на просмотр), сделал некоторые профилирования и оптимизировал, если это необходимо. Преждевременная оптимизация - это корень всего зла.