Comments 6
Возможно стоит добавить, что одним из основных отличий от managed beans является то, что такие бины не managed :) Т.е. становятся недоступны такие плюшки, как управление транзакциями, security и т.д.
Абсолютно верно, спасибо за комментарий. В данном случае мне просто не хотелось усложнять. Как я написал в начале, Weld не привязан к какой-либо платформе, поэтому если он будет использоваться без EJB контейнера, то там плюшек транзакционности и security все равно нет, но в любом случае будут другие =)
Мне кажется, когда появляются дополнительные требования их надо применять к текущей реализации, а не писать новую. Старая то не понадобится в 99% случаев + сложность не растет + имеется в vcs.
Ну, а если же, имеется несколько реализаций, нафик нужен ioc, если ему надо явно указывать, да еще не в 1 файле, что использовать? Добавить аннотации к реализации, указать аннотацией какую использовать. Ведь куда проще сразу в коде использовать необходимую
Ну, а если же, имеется несколько реализаций, нафик нужен ioc, если ему надо явно указывать, да еще не в 1 файле, что использовать? Добавить аннотации к реализации, указать аннотацией какую использовать. Ведь куда проще сразу в коде использовать необходимую
В простом случае IOC вообще не нужен. Где-то даже встречал список распространенных ошибок начинающего джава-разработчика и повсеместное прикручивание IOC там было (сейчас смог найти только эту статью, правда по .NET, но общий смысл ясен). Действительно зачем создавать какие-то DI, когда всего пара интерфейсов на приложение (например)?
А в большом приложении IOC необходим (ну не зря же его придумали-то в конце концов=)), т.к. хотя бы дает возможность разбить приложение по отдельным кусочкам и проще покрыть модульными тестами. То что конфигурация хранится в нескольких файлах, возможно это минус с одной стороны, но с другой, как мне кажется, это намного лучше чем конфиги спринга в которых это все лежит. Т.е. чтобы понять какая именно реализация куда инжектится, Вам нужно искать это в xml (ну или не придется, если используются аннотации со строчной константой, а это, по словам разработчиков weld, зло). Ну и опять же повышается читабельность и уменьшается возможность совершить ошибку.
В коде действительно проще использовать необходимую. И опять же в простых случаях так и нужно делать, но разве это не повышает связность?
А в большом приложении IOC необходим (ну не зря же его придумали-то в конце концов=)), т.к. хотя бы дает возможность разбить приложение по отдельным кусочкам и проще покрыть модульными тестами. То что конфигурация хранится в нескольких файлах, возможно это минус с одной стороны, но с другой, как мне кажется, это намного лучше чем конфиги спринга в которых это все лежит. Т.е. чтобы понять какая именно реализация куда инжектится, Вам нужно искать это в xml (ну или не придется, если используются аннотации со строчной константой, а это, по словам разработчиков weld, зло). Ну и опять же повышается читабельность и уменьшается возможность совершить ошибку.
В коде действительно проще использовать необходимую. И опять же в простых случаях так и нужно делать, но разве это не повышает связность?
А на сколько корректно использоваться аннотацию @Override в случае реализации, а не перегрузки метода? На первый взгляд это кажется не правильным…
Sign up to leave a comment.
Dependency injection в Java EE 6