Я просто понимаю, как написать хорошую архитектуру хорошего программного обеспечения , и я изучаю, как разделять компоненты высокого уровня на слои. В этом случае я пытаюсь использовать Tiers, чтобы смоделировать каждый слой как черный .Проблема дизайна публикации/подписчика N-уровня
В моей архитектуре 4 уровня: презентация, прикладные услуги, Бизнес-логика и домен/постоянство. Для целей моего вопроса, , нам действительно нужно сосредоточиться только на презентации и приложениях.
Слой прикладных услуг будет содержать Сервис, который позволяет отслеживать определенного события. Презентация будет иметь несколько представлений, которые должны обновляться динамически при изменении модели отслеживания событий. По существу, кажется, что мне нужен односторонний механизм распространения изменений.
Поскольку я пытаюсь моделировать эти слои как ярусы, я хотел бы ограничить общение между объектами фасадов для каждого уровня, и в случае необходимости, позволяет Tier агрегировать объект из одного уровня ниже, хотя только известный по интерфейсу.
Я программирую это приложение на Java, поэтому очевидная вещь для использования - Observable/Observer. Тем не менее, мне не нравится, что метод обновления для интерфейса Observer заставляет вас использовать аргументы объекта. Я хочу обойти , указав свой собственный интерфейс и класс для этого механизма. Таким образом, проблема заключается в том, что логика приложения будет зависеть от интерфейса от представления Tier, определенного для этой архитектуры нет-нет. Является ли это признаком того, что я должен попробовать моделирование с помощью MVC fore-most и Layer the Model? Или было бы лучше, если бы модель смоделировала каждый из видов с интерфейсом, известным на уровне приложений. Кажется, это плохое место, и я застрял. Кроме того, я использую шаблон проектирования View-Handler для обработки нескольких видов.
Я согласен - классы Observer/Observable были добавлены в исходные спецификации java и были такими же бесполезными, как сегодня. Хотелось бы, чтобы они осуждали и избавлялись от них, поскольку все, что они делают, путают людей и ведут их по неправильному пути. – rancidfishbreath
Это звучит как хорошее решение. Однако мне трудно понять, как базовая модель на Уровне услуг распространяет информацию на уровень презентации. Если презентация содержит прослушиватель действий, который является регистром для модели, как представление извлекает нужные ему данные при запуске этого объекта PropertyChangeEvent? – Mike
Я предположил, что уровень сервиса обеспечит способы получения данных для уровня представления, но в любом случае [PropertyChangeEvent] (http://java.sun.com/j2se/1.4.2/docs/api/java/ beans/PropertyChangeEvent.html) имеет методы getPropertyName() ',' getOldValue() 'и' getNewValue() '. Тот, кто пожалеет событие, должен заполнить соответствующую информацию. Вы также можете основывать свои действия на Action и ActionListeners или получать собственные пользовательские события и EventListeners, в зависимости от того, что имеет наибольший смысл с учетом (неизвестных мне) деталей вашей системы. –