Наткнувшись недавно на статью New Features in EJB 3.1 - Part 4, которая обещала рассказать об интеграции с EJB с Web Beans, я немедленно заинтересовался. Дело в том, что спецификация JSR 299: Web Beans, находящаяся в стадии разработки, многими преподносится едва ли не как "the most exciting JSR being developed in the Java EE 6 timeframe", не говоря уже о том, что она основана на идеях активно рекламируемых JBoss Seam и Google Guice. Таким образом, Web Beans естественным образом попадает в поле зрение любого разработчика, имеющего дело с Java EE. Вкратце, это штука унифицирует компонентые модели EJB и JSF (да и все остальные компонентные модели, в принципе, тоже), позволяя использовать EJB в качестве JSF managed beans и предоставляя мощный механизм dependency injection, позволяющий при помощи аннотаций всунуть что угодно куда угодно. В общем, это первая кандидатура на звание главной блестящей и мигающей игрушки в мире Java, которая в короткие сроки должна окончательно добить и отправить на свалку истории .NET и прочую туфту типа PHP и Ruby.
Я, однако, до последнего времени не спешил присоединятся к всеобщему восторгу в отношении Web Beans, так как, прочитав несколько статей от авторов спецификации и отдавая должное прикольным штукам, которые можно будет проделать с ее помощью, я никак не мог придумать, где бы я стал эти штуки использовать в своих собственных проектах. К тому же, я вообще как-то не очень хорошо понимаю, чем хороша идея использовать EJB, которые всегда представлялись мне компонентами инкапсулированной бизнес-логики, для построения веб-интерфейса. И вот, встретив статью, написанную с точки зрения EJB 3.1 (а уж относительно этой технологии я абсолютно точно знаю, где мне хочется ее применить), я надеялся, что уж теперь-то меня убедят и я тоже смогу порадоваться близкой победе сил добра над силами зла.
Не тут-то было.
Прежде всего, статья вообще ничего не говорит о том, что нас ждет в плане EJB 3.1. Она просто содержит выдержки из того, что все и так уже знали о Web Beans, дополненные парой примеров. Первый пример стандартный (он как раз иллюстрирует использование stateless EJB в качестве JSF managed bean, причем без каких-либо попыток объяснить, почему от применения такой архитектуры наша жизнь станет лучше), зато второй - просто убийственный. Он настолько удивителен, что я его приведу полностью.
Итак, второй пример демонстрирует возможность инжекции произвольного объекта (в отличие от Java EE 5, где инжекцию можно делать только для стандартных типов компонент типа EJB или Datasource). Теперь же, благодаря мощи Web Beans, нам предлагается с помощью механизма DI использовать... классы-утилиты! Выглядит это так:
@Componentpublic class MathUtil {
...
public static double round(double value, int decimalPlaces) {
BigDecimal converter = new BigDecimal(Double.toString(value));
converter = converter.setScale(decimalPlaces, BigDecimal.ROUND_HALF_UP);
return converter.doubleValue();
}
...
}
@Component
@Stateless
@Named("placeBid")
public class PlaceBidBean {
@PersistenceContext
private EntityManager entityManager;
@In
private Bid bid;
@In
private MathUtil mathUtil;
public void addBid() {
bid.setBidPrice(mathUtil.round(bid.getBidPrice(), 2));
entityManager.persist(bid);
}
}
Я, наверное, очень примитивный человек, так как совершенно не в состоянии понять, в чем польза от вызова статического метода класса через ссылку на экземпляр этого класса, еще и полученную с помощью Dependency Injection, равно как выше моего понимания, как возможность такого извращения служит примером гениальности новой технологии.
Я понимаю, что примеры в статьях должны быть по возможности простыми. Я не понимаю, почему примеры не могут иллюстрировать нечто вроде "Вот смотрите, раньше, чтобы сделать эту нужную операцию, вам приходилось напрягаться и писать много некрасивого и опасного кода. А теперь, благодаря нашей чудо-технологии, вы пишете пару аннотаций - и опаньки, все уже работает, причем лучше, быстрее и надежнее, чем было раньше ". И почему вместо этого так много примеров выполнены в стиле "Зацените, как клево можно теперь извратиться! Раньше вы такие извращения и представить себе не могли!".
P.S. Я по-прежнему считаю идею о смешивании в одну кашу уровней интеграции с БД, бизнес-логики и построения интерфейса по меньшей мере сомнительной. Может быть, в определенном ограниченном классе приложений это и имеет смысл; но вряд ли этого достаточно для того, чтобы преподносить эту новую игрушку в качестве "the most exciting JSR". Вообще, в Java EE 5 уже все хорошо в плане двух первых из упомянутых уровней; здесь нужна уже не революция, а эволюция, которой и являются EJB 3.1 и JPA 2.0. А вот на уровне веб-интерфейса нужно серьезно поработать, чтобы превратить JSF в технологию, которой приятно пользоваться. В начале работы над JSF 2.0 говорилось о многих очень правильных вещах; а недавно экспертная группа опубликовала Early Draft Review, изучением которого я, по мере воможности, сейчас и занимаюсь.
No comments:
Post a Comment