Дорога в совершенство

Хо-хо!
Третий день занят разработкой некоей магической штуки, которая должна мне помочь разруливать конфликты паралельного и последовательного доступа ко всяким там методам китайского чудо-класса, при том инициация доступа будет делом рук юзера. А с юзером, если у него есть кнопка, шутки плохи.
Задача.
Есть DataSet, местами даже типизированный, агрегированный в некий класс, методы которого его собственно и заполняют. Разные методы возвращают данные в общие таблицы, т.е., по простому, кого последнего вызвали, того и данные. Это все типа как DAL + Модель. Естественно, существует еще и View и Presenter. Обычный MVP. Разные контроллы представления используют общие таблицы, но отображают каждый свои данные. То есть, чтобы отобразить данные представления, необходимо вызвать сперва один метод DAL, сохранить данные в какую-то другую таблицу, связанную с контроллом А, потом вызвать тот же запрос, но с другими аргументами, сохранить новые данные куда-то еще, чтобы никто их не перезаписал позже и т.п.
Как бы ничего сложного?)
Теперь добавим условие, что запросы могут выполняться долго, или даже ДОЛГО. А представление не должно при этом висеть. То есть, каждый запрос в своем потоке. В общем, доставка данных асинхронная. Значит, нужны точки синхронизации данных, в которых данные будут привязываться к контроллам, а в переходном состоянии контроллы просто не реагируют на пользователя.
Все еще просто! Ха-ха-ха.
Добавилось теперь еще условие - некоторые переходные состояния могут прерываться для перехода в другое переходное состояние. Например, если долго грузятся данные по одним параметрам, юзер может ввести другие значения и вызвать другой запрос уже по ним. Кроме всего, нет возможности в чудо-классе прерывать ожидание данных, равно как и вызвать запрос, если он уже занят - надо ждать его завершения. При этом, разумеется, о состоянии запроса тоже ничего наружу не сообщается, т.е. для каждого вызванного метода надо помнить его состояние вплоть до освобождения. Ну, в нагрузку, многие переходы требуют выполнения нескольких запросов паралелльно, а еще, при инициализации вследствие последовательного использования объектов-таблиц, требуется выполнить несколько "многозапросных" переходов. При этом, инициализация может быть повторно вызвана пользователем. В любое время.
Задача, на самом деле, простая. Только ее надо выполнить раз эдак 50, причем на разных схемах DataSet для разных представлений со своими переходами и состояниями. Да ,еще, все классы генерятся по шаблону, а в китайской чуде ничего менять нельзя.

О решении дальше...

Вам это будет интересно!

Последние новости