?

Log in

No account? Create an account

Previous Entry | Next Entry

Появилась новая статья. А с ней - и новый раздел. "Архитектура". Давно хотел начать писать в этом направлении, да все никак не складывалось. Была одна статья о синглтонах, но больше про технику реализации.

И вот, наконец, сложилось. Статья о принципах модульного проектирования. Как сделать так, чтобы модуль можно было переиспользовать. Читайте: http://www.skipy.ru/architecture/module_design.html.

Обсуждение – в этой теме.

Comments

(Anonymous)
Sep. 28th, 2010 09:38 am (UTC)
Локатор сервисов
Здравствуйте Евгений, благодарю вас за статью. Очень хорошо написана. Жаль что в сети мало вот таких вот статей про архитектуру. У меня есть несколько вопросов относительно локатора сервисов:
1)Кто отвечает за конфигурацию и заполнение локатора? Конфигурацию можно сделать в xml или аннотациях. Локатор должен их прочитать и сам себя заполнить. Так или нет?
2)В локаторе должны находиться только экземпляры зависимостей и тех кто от них зависит или что то еще?
Если делать конфигурацию аннотациями как вы написали в статье то:
3)какие параметры должны быть указаны в @Provider и @Injection?
4)как эффективно искать классы помеченные именно этими аннотациями? Не переберать же все классы из cp?
5)Где можно посмотреть пример такого локатора с аннотациями?
Изменяюсь, за такое большое кол-во вопросов, но надеюсь что вы ответите.
skipy_ru
Sep. 28th, 2010 10:06 am (UTC)
Re: Локатор сервисов
Добрый день, анонимный товарищ! :)

1. Ну, в принципе так. Лучше на XML, аннотации все-таки надо искать.

2. Да, локатор предназначен для создания дерева зависимостей. Все остальное там лишнее.

3. Дело в следующем. Если мы будем, например, ориентироваться только по имени класса - мы получим по одному экземпляру каждого типа. А если их нужно несколько? Например, DataDestination - на его базе можно сделать лог. Т.е. в модуле мы будем иметь не один экземпляр DataDestination, а два. Работа с ними идентичная, что нам и надо. А вот получение - в одном случае я могу написать, скажем, @Injection(Type.business), в другом - @Injection(Type.log). Считаем, что enum Type определен. Ну и две реализации - @Provider(DataDestination.class, Type.business) и @Provider(DataDestination.class, Type.log). Соответственно, при внедрении зависимости по классу и конкретному типу мы можем найти нужный экземпляр.

4. При старте - не надо, это долго. А вот при сборке - да. Других вариантов нет. Сканируется наш jar (только наш, а не весь classpath, что уже существенно лучше), всё, что найдено с аннотациями - собирается. Потом пишется xml, на который и будет ориентироваться локатор.

5. Ну... разве что я соберусь и напишу. :) Когда время найду.