Правильная организация контроллера в клиентском приложении

[КорДум]

Приветствую, товарищи!
Значит, имеем механизм RPC, много бумажек с протоколами сервера, в которые входят серверные методы (которые нужно вызывать с клиента у сервера) и клиентские методы (которые нужно вызывать наоборот, с сервера у клиента). Их на самом деле очень много, у серверных, к тому же, первым аргументом нужно коллбэк подавать.

Также имеем приложение на MVC, базовый контроллер которого создает NetConnection-подключение, в качестве клиента передает себя и...содержит около 70 методов, как коллбэков, так и публичных-клиентских. Это не считая приватных методов, что получаются в ходе рефакторинга парсинга информации, что поступает с коллбэками.

Серверные методы я выделил в отдельный класс, обернул их в статик, так и вызываю. К слову, мне очень не нравится использовать в этом месте статику, но, видимо, деваться некуда. А вот что делать с этим большим количеством методов в контроллере - ума не приложу. Сейчас написаны только пустышки, а оно занимает около 600 строчек. Не comme il faut и вызывает судорогу.

Все коллбэки принимают параметр - строку/число, которую надо парсить/сравнивать, все данные пишутся в модель.

И вот вопрос: как лучше организовывать такие большие объемы методов?

[Bgg]

Сообщение от КорДум

И вот вопрос: как лучше организовывать такие большие объемы методов?

Разбить их на классы))

[КорДум]

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

А вы что предлагаете?

[Bgg]

Я чесногоря не очень понимаю нафига тут статичные методы вообще. Я бы создал класс NetController, ссылка на который была бы в главном контроллере. NetController содержал бы эксземпляр класса NetConnection в котором были бы описаны все методы ваши эти. NetController парсил бы ответы от NetConnection и решал бы что отдать главному контроллеру посредством коллбеков или событий.

И не понятно что это за 70 методов. Их наверняка можно поделить на классы получения данных, инициализации объектов, сохранения данных на сервер.

[in4core]

Ужасно )) а куда деваться ))) Сань я честно не вкурсе, с чего ты создал эту тему, твой подход вполне обоснованный. Проблема вся кроется в том, что тебя заставляют еще и парсинг данных делать - издеваются ))) Такая же бибоба у меня была на конях, ты код смотрел?
Есть класс работающий только на получение данных ( все статик ) и диспатчит приход этих данных ( там же идет парсинг ( подключаем доп класс внутрь ) , другой записывает и производит работу с этими данными ( создает фреймворк ). Если конечно хочется поизвращаться улучшить читабельность , то можно создать еще и менеджер данных, да и парсить там же.
Однако в твоем случае, есть еще небольшая проблема : некоторые методы отрабатывают напрямую во фреймворке, а вот некоторые в отдельных субКлассах . Завести общий диспатчер - можно, но нужно ли? Если создашь , то будешь из какого нить класса оповещать все модули об изменении, иначе же использовать перекрестный статик, в чем ничего плохого нету.

SubClass A
....
FrameWork.call ('method1' , someCallBack);
_____
Class FrameWork
....constructor
_dispatcher.addEventListener ( m , someFunc )
....
function call(m:String , callBack:Function) {
     Server.call ( m )
    this._callback = callBack;
}
function someFunc(e:SomeEvent) {
    _callback(e.vars);
}

[КорДум]

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

Так, значит создаем еще один коннект-контроллер в базовом контроллере, передаем ссылку на вьюшку и модель. В нем создаем отдельные контроллеры, в них передаем те же вьюшку и модель (кому что надо, в смысле), верно?
А парсинг-методы где живут? В коннект-контроллере?

А как быть с публичными методами клиента, которые вызывает сервер?

Добавлено через 1 минуту
Сань, ты же знаешь, у меня сейчас "чай с плюшками". Вот и выжимаю из проекта все, что можно. В данном случае для опыта, ну и для читабельности и разбыдлокодирования. Вот.

Добавлено через 2 минуты
И кстати да, у тебя методов серверно-клиентских, кажется, меньше раза в два, чем у меня.

[in4core]

Бесит еще то что приходится и от сервера получать и самому его дергать. Получается двойная пляска по кочкам. В конях у меня только сервер меня дергал - и было пофигу, а тут приходится чуть подзапарится с разносом данных

[gloomyBrain]

Вы правда о лошадях говорите, или я что-то пропустил? =)

А вообще - можно же разбить колбеки на категории и завести, например, 7 классов, каждый с 10 методами. Гораздо удобнее, и синтаксис будет поприятнее

// вариант когда все в одном месте
netController.updateModelUserPoints()
 
// вариант с 10 классами
netController.moel.user.updatePoints()

Мне второй вариант кажется выигрышным

[КорДум]

Вы правда о лошадях говорите, или я что-то пропустил? =)

Да-да, на самом деле. Я разглашать не буду

Мне второй вариант кажется выигрышным

То есть нужно мне вызывать вот так:

СтатикСерверныйМетод(netController.moel.user.updatePoints, параметр1, параметр2)

? А как в случае с публичными клиентскими методами? Их тоже немало. Если только... сделать оболочку для них, указать в качестве клиента netConnection экземпляр оболочки. В методах оболочки вызывать методы, которые я расфасовал по разным классам?

[gloomyBrain]

А как в случае с публичными клиентскими методами?

Да точно так же. Делаешь несколько классов, создаешь несколько экземпляров, передаешь им ссылку на NetConnection. То есть, в данном случае NetConnection - это модель, в которую нужно правильно записать. Методы этих классов принимают разные параметры, форматируют их и отдают на сервер.

ЗЫ
На счет статиков - не понятно, зачем тут вообще они нужны? Ты же не лепишь статичные модели данных в своих приложениях? А чем NetConnection хуже? Короче, статик лучше оставить для констант, конфигов и прочей ерунды, которую ты точно не будешь использовать еще раз.