Помогите с архитектурой приложения
 

Есть небольшое приложение в локальной сети для отслеживания игроков на разных серверах.

Текущая архитектура такая:

Есть два (в будущем больше) источников данных. Для каждого источника написан класс(адаптер) для удобного забора данных. Адаптеры содержат внутри себя таймеры, которые асинхронно обновляют данные с источников. Интервалы обновления(t1,t2) не одинаковые.

Второй частью приложения является список с игроками, за которыми ведется наблюдение. Каждый игрок(User1,User2...) это класс, где содержится инфа о нем. Через определенный интервал времени(t3) осуществляется обновления списка. Классы дергают адаптеры и забирают изменившиеся данные.Если известны ники для двух серверов, опрашиваются два адаптера. Возможна ситуация, когда известен только один ник на одном сервере, в этом случае другой адаптер не опрашивается.

Адаптеры написаны как синглтоны и ссылка на него хранится внутри классов игроков.

Сейчас получается потеря времени в случае когда данные уже обновлены, а время для перебора списка еще не подошло.

Да и вообще получился быдлокод.

Может у кого есть идеи по оптимальной архитектуре для такого приложения.

Судя по схеме через t3 перебирается весь список игроков и отправляется запрос адаптеру от каждого. А может лучше завести таймер каждому игроку? То есть проходит t3 времени и объект игрока шлет запрос. Тогда можно будет смотреть внутри объекта игрока, например время обновления пришло, но ответ на прошлый запрос не пришел, оборвать запрос, и послать новый или просто ждать ответа. То есть я думаю что механизм обновления инфы об игроке надо инкапсулировать в самом классе игрока. К тому же не будет такого, что раз в t3 ваши 100500к игроков нападают на сервер чтобы обновить инфу, а будут слать запросы тогда, когда надо

Адаптеры используются как прокси данных. Они сами по своей инициативе забирают данные, парсят их и сохраняют в себе. На все запросы статусов игроков возвращаются сохраненные данные( от предыдущего ajax запроса).

epson,
А, ну тогда можно сделать чтобы игроки не раз в t3 дергали адаптер, а чтобы слушали события адаптера, адаптер обновился - отправил событие, игроки (кому надо) среагировали и обновились, а кому например еще не надо, или не может, запомнили, мол если что, можно обновиться, т.к есть обновленные данные

Да, с событием хорошая идея.
Только вот как отправлять события?
Разве в js можно создавать пользовательские события для своих объектов?
Можно ссылочку или кусочек кода

Естественно события надо будет вручную отправлять. То есть адаптер скачал инфу, и вызвал у себя this.fireEvent("datareceived", data). А обработчик в свою очередь перебирает всех подписчиков, и передает им что нужно, или только тем кому надо, там уж от специфики приложения зависит. Есть паттерн такой Observer, реализаций тьма. Мне часто приходится пользоваться фреймворком Ext, там все компоненты от него наследуют. Ext.utul.Observable, можете код посмотреть. Если используете jquery, то события можно поджигать методом trigger. Например

var Adapter = function () {
	Adapter.prototype.init.apply(this, arguments);
}


Adapter.prototype = {
	
	players: [],
	
	init: function () {
		jQuery.bind(this, "datareceived", function (data) {
			jQuery.each(this.players, function (player) {
				if ( player.isNeedUpdate() ) {
                                        // или всегда отправлять игроку data, а у игрока завести массив с обновлениями, и если ему надо обновиться, то он обновляется из него
					player.update(data);
				}
			});
		});
	},
	
	downloadData: function () {
		
		var data = doSomething();
		
		jQuery.trigger(this, "datareceived", data);
	},
	
	addSubscriber: function (player) {
		this.players.push(player);
	}
	
}

Большое Спасибо!
Это как раз то, что мне было нужно