Архитектура модульного приложение

[mue]

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

Пока логика всего приложения не сильно сложная, все просто.

Но если допустим все приложение имеет несколько состояний ( по сути их может быть сколько угодно ) и все модули слушают какое сейчас состояние.
При такой архитектуре приходиться в каждом модуле описывать его поведение, при всех состояниях, что довольно накладно и получается много кода.

Как вы решаете подобные проблемы ?

[megaupload]

Я зарание описываю в определенном месте все ВИДЫ того на что можно подписываться. И логику поведения и работы с этим.


например есть событие - ввод текста
или - перенесли drag n drop файл


и логика каждого из таикх событий описана в самом событие, у этой ЛОГИКИ есть свой API а вот К КОТОРОМУ то и подключатся подули ПОДПИСЫВАЯСЬ на это событие.

суть такая что у модулей есть интерфейсы - входы и выходы, например есть вход text и выход text

если я пытаюсь подписать модуль на событие text (out) другого модуля, то все подпишется автоматически в нужный канал.. и API text (out) сразу подключится так как надо (потому что добавляя в модуль поддержку вход text и выход text я сделал в нем точки подключения API события text а ЛОГИКУ этого Api я описал в месте где описаны ВСЕ ВОЗМОЖНЫЕ события ВСЕХ модулей)

логика примерно понятна? я могу пример привести если надо)

[megaupload]

то есть тупо говоря те нужно в одном месте описать логик поведения интерфейса text

описываем

interfases.add('text', {api: {/*api*/}, /*логика*/});


создаем модуль и указываем какие интерфейсы он имеет

modules.add(interfases:['text']);

[megaupload]

бля ну корчое вломы придумывать но если оч нужно то напишу)

[megaupload]

инкапсулируй короче логику поведения интерфейса (события) где нить один раз, и сделай этому интерфейсу точки подключения API К КОТОРЫМ потом прикручивай этот интерфейс (событие) в модулям через API


интерфейс будет описан один раз, например (text out) а использовать его смогут разные модули подключая его к себе через его API

[mue]

Я так понимаю если логика закладывается в само событие, то получается жесткая связанность между модулями.

К примеру, у нас есть событие, что пользователь выбрал дату в календаре, и календарь генерит событие с указание даты. Теперь если в этом событие установить логику, например сказать, что эта дата должна быть отображена на экране, значит событие жестко знает что есть модуль который может отображать дату. И в итоге мы связали календарь и модуль для отображения даты, чего пытались изначально избежать.

Или я не понял как работаеит твоя схема.

Можешь прислать какой-нить полноценный кусок кода посмотреть как все работает.

[megaupload]

бля короче роутер напиши и в роутер пихай все события и все их api, подписывая модуль на событие при подписке подключай api модуля к api события

[megaupload]

у тя так



а надо так



допустим приходит в сокет text в канал in какой нить текст

роутер смотрит кто у нас там может обрабатывтаь текст и кто на него подписан на его канал out и отдает текст ВСЕМ кто подписан




п.с. МНЕ ОБЯЗАТЕЛЬНО код писать? просто я щас занят изучением кое чего и пилкой портфолио)

[megaupload]

если ты отправляешь текст определенного типа

который должен рассылаться НЕ ВСЕМ модулям а только определенным которые могут обрабатывать ИМЕННО ТАКОЙ текст, то это значит что это не просто текст и это повод создать для него отдельный сокет) суть в том что если кто то ПОДПИСАН НА ТЕКСТ то ВСЕМ будет РАЗДАВАТЬСЯ ТЕКСТ и ВСЕ БУДУТ ЕГО ОБРАБАТЫВАТЬ.

то есть text и messageText


то ест НЕ НУЖНО делить сокет "text" на какие то подвиды текста... надо всегда создавать новые сокеты. чтобы было все чотко.

суть такова что модули ВООБЩЕ не должны ни чо знать друг о друге.. только о роутере.

[Riim]

в каждом модуле описывать его поведение, при всех состояниях, что довольно накладно и получается много кода

каждое состояние делается в виде отдельного подмодуля, основной модуль содержит логику переключения между состояниями.

Все модули не знают друг о друге, работают они исключительно на событиях, которые генерят другие модули

создается общий слой, куда все модули "сбрасывают" свои события, и через который подписываются на события других модулей. Видимо, роутер который описывает megaupload, как раз и есть такой слой, непонятно только зачем там что-то к интерфейсам приводится (видимо просто корявая реализация паттерна наблюдатель). Обычно в качестве такого слоя выступает корневая въюшка приложения.