Проблема N-Tier Publish / Subscriber Design

Question

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

В моей архитектуре 4 уровня: презентация, службы приложений, Бизнес-логика и домен / постоянство. Для целей моего вопроса, нам действительно нужно сосредоточиться только на службах презентаций и приложений.

Уровень сервисов приложений будет содержать сервис, который позволяет отслеживать определенного события. Презентация будет иметь несколько взглядов, которые должны обновлять динамически при изменении модели отслеживания событий. Неотъемлемо, похоже, мне нужен односторонний механизм распространения изменений.

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

Я программирую это приложение на Java, поэтому очевидная вещь для использования Наблюдаемый / наблюдатель. Однако мне не нравится, что метод обновления для Интерфейс Observer заставляет вас приводить аргументы объекта. Я хочу обойти это путем определения моего собственного интерфейса и класса для этого механизма. Эта проблема, то, что логика приложения будет зависеть от интерфейса из презентации Уровень, определенный нет-нет для этой архитектуры. Это знак того, что я должен попробовать моделирование с помощью MVC и Layer the Model? Или было бы лучше моделируйте каждое из представлений с помощью интерфейса, известного на уровне служб приложений. Кажется, это плохое место, и я застрял. Кроме того, я использую шаблон проектирования View-Handler для обработки нескольких представлений.

Answer 1

Мне кажется, что ваш вопрос не столько о публикации / подписке, сколько о том, как заставить слои взаимодействовать.

Краткий ответ:

Используйте MVC / MVP. Посмотрите на них сообщения в блоге, загрузите исходный код и помните: если у вас есть только молоток, все выглядит как гвоздь. То есть не применяйте шаблоны, потому что они у вас есть, применяйте их, потому что они вам нужны.

Длинный ответ:

Если вы работаете на Java, я предлагаю Шаблоны проектирования в первую очередь , которые помогут вам сориентироваться в образе мышления. После того, как вы разберетесь с шаблонами проектирования, к которым, я думаю, вы приближаетесь, вы можете взглянуть на Шаблоны архитектуры корпоративных приложений . Не стесняйтесь пропустить Head First, но это очень хорошая книга, которую я очень рекомендую, если вы начинаете изучать архитектуру.

После того, как вы переварили книгу Фаулера или, по крайней мере, приобрели базовое понимание архитектуры N-Tiered Enterprise, вы должны быть в курсе.

Answer 2

Observer / Observable часто не лучший подход, особенно в Java, где вы должны извлечь из Observable, тратя впустую ваше единственное наследование.Это также, как вы обсуждаете, вызывает связь, которая является плохой, когда она пересекает уровни.

Я был бы более склонен исследовать чистую модель Event, с сервисами, обеспечивающими способ регистрации EventListeners и запуска, возможноPropertyChangeEvent, когда происходит изменение.

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