Разработка архитектуры на основе плагинов поверх Spring - PullRequest
5 голосов
/ 07 декабря 2011

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

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

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

Еще один вопрос, о котором я подумал, - это АОП на основе аннотаций, где я аннотирую каждый метод, где плагин будет перехватывать методы на основе определенных соглашений. Моя проблема в том, что, во-первых, я не очень разбираюсь в AOP в целом, а во-вторых, просто написание всех этих соглашений уже предполагает некоторую связь

Безусловно, вариант, который больше всего подходит для моего мышления, - это использование событий на основе Spring. Каждый тип обработчика запросов в моем приложении (веб-контроллер, обработчик электронной почты и т. Д.) Будет своего рода диспетчером событий, который будет отправлять события Spring для каждого важного действия. С другой стороны, плагины просто прослушивают, когда происходит определенное событие, и выполняют некоторую логику. Это позволит мне также использовать пункт № 1, так как некоторые из этих плагинов также могут быть фильтрами, то есть, когда они получают уведомление о том, что определенное действие контроллера выполнено, они могут просто решить ничего не делать и скорее ждать, когда они вызваны цепочкой фильтров. Я считаю это несколько приятным подходом. Конечно, здесь снова возникают накладные расходы, связанные с отправкой событий, плюс тот факт, что каждый участвующий класс навсегда будет связан с Spring, но я вижу в этом неизбежное зло.

Мое основное беспокойство по поводу событий Spring - это производительность, как с точки зрения задержки, так и объема памяти.

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

Спасибо.

1 Ответ

1 голос
/ 07 декабря 2011

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

Ваша идея использования событий называется «Архитектурой, управляемой событиями». Это идет намного дальше, чем просто плагины, потому что он не только отделен от реализации, но также предлагает возможность отделить от того, какой экземпляр используется (несколько обработчиков), какое местоположение (несколько машин) и время обработки запроса (асинхронный обработка). Компромисс заключается в увеличении общей сложности, уменьшении сложности на уровне компонентов и необходимости в инфраструктуре обмена сообщениями. Часто используется JMS, но если вам просто нужна установка с одним узлом, Spring и Mule также предлагают простые режимы в памяти.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...