Comments 8
Че-то даже обсуждения нет никакого. А тема-то интересная…
Для web приложений существует подобный подход www.slideshare.net/nzakas/scalable-javascript-application-architecture
Довольно удобно в реальной жизни.
Довольно удобно в реальной жизни.
Компания, в которой я работал раньше, делала компонентное приложение. Года 3 писали, там все красиво — компоненты еще на уровне maven, можно включать-выключать во время сборки, ядро само определяло, что включено, а что нет. В итоге все ведущие программисты уволились — им стало скучно, проект заглох, компания наняла индусов, а потом и вовсе расформировалась.
Но компонентная архитектура — это круто, да.
Но компонентная архитектура — это круто, да.
Писали и будем писать!
При использовании EventBuses не обязательно разрегистрироваться, хотя и желательно, например EventBus из Guava регистрирует WeakReference на listener. Eсли правильно использовать IoC контейнер, то все мероприятия по сборке/разборке component assembly должен делать именно он. Компонент не должен вручную контролировать свой lifecycle. Для этого существуют Scopes.
В статье в основном идет речь об интерфейсном слое. Он важен для узкого куга десктопных приложений. А есть еще web, mobile, services etc. На мой взгляд основная сложность производственных приложений лежит в модельном слое предметной области и в возможности его настраивать и повторно использовать. Именно предметная область должна диктовать условия интерфейсному слою.
Пользовательский интерфейс в статье был использован для того, чтобы подвести к тому самому модельному слою, о котором вы упоминаете. В нашем случае модель приложения динамическая и она определяется в XML формате. За центральным контроллером стоит интерпретатор этой модели.
Самое важное, на наш взгляд — это то, что модель является асинхронной, основанной на событиях. В отличие, например, от модели приложения заданной на основе классов или созданной посредством кодогенерации из статической диаграммы.
Мы стремимся к тому, чтобы модель описанная с помощью Lexaden Web Flow, можно было повторно использовать для desktop, web, mobile, services и других приложений.
Технически это вполне можно сделать уже сейчас. Но на данном этапе мы не пытаемся объять необъятное. Поэтому сфокусировались лишь на проблеме адаптации приложения к разным рынкам и разным клиентам в рамках одной веб-платформы.
Как результат, модельный слой стал диктовать, как будет работать интерфейс приложения. При этом, на наш взгляд, улучшилось юзабилити системы, в частности навигация по модели приложения.
И это только часть тех выгод, которые можно получить, использовав эту технологию уже сейчас.
Самое важное, на наш взгляд — это то, что модель является асинхронной, основанной на событиях. В отличие, например, от модели приложения заданной на основе классов или созданной посредством кодогенерации из статической диаграммы.
Мы стремимся к тому, чтобы модель описанная с помощью Lexaden Web Flow, можно было повторно использовать для desktop, web, mobile, services и других приложений.
Технически это вполне можно сделать уже сейчас. Но на данном этапе мы не пытаемся объять необъятное. Поэтому сфокусировались лишь на проблеме адаптации приложения к разным рынкам и разным клиентам в рамках одной веб-платформы.
Как результат, модельный слой стал диктовать, как будет работать интерфейс приложения. При этом, на наш взгляд, улучшилось юзабилити системы, в частности навигация по модели приложения.
И это только часть тех выгод, которые можно получить, использовав эту технологию уже сейчас.
Если кому интересно, то вышло проложение этой статьи: Навигация: вариант реализации для корпоративного приложения с более подробными деталями реализации описанного решения.
Sign up to leave a comment.
Есть ли будущее за компонентной архитектурой?