Java beans, что где когда

JSF используется на фронтенде. Это формочки, различные AJAX-компоненты. Плюс управление жизненным циклом обработки запросов. Технология подменяет собой устаревшие JSP/Servlet (оборачивает их) и заменяет «местечковые» фреймворки типа Struts.

EJB используется для реализации бизнес-логики. Бизнес-логику в принципе можно засунуть и в JSF, но тогда получится только Web-приложение.

Всё это очень сложно. Насыщенно программирвоанием на XML.

все это дерьмо, щас народ которы-любит-технологи писает кипятком от spring, тот народ который не любит гемморой - не юзает эту ынтерпрайз порнографию, и только в банках где банки с плесенью можно встретить java 1.4 и EJB

Сможете порекомендовать годную литературу по этому поводу (на английском, вероятно) ? Без скриншотов установки Eclipse/Netbeans, но с пояснением сути.

По JSF: Дэвид М. Гери, Кей С. Хорстманн JavaServer Faces. Библиотека профессионала, 3-е издание ISBN 978-5-8459-1706-5, 978-0-13-701289-3 — лучше этой всё объясняющей понятным русским языком не встречал.

По EJB не интересовался больше. Ну нафик такую сложность.

Сейчас модно весь энтерпрайз в концепции OSGi писать. Посмотри фреймворки Eclipse Scout и Eclipse Riena в книжке Eclipse: разработка RCP-, Web-, Ajax- и Android-приложений на Java, может заинтересует. Там же описаны методы доступа к данным и работа с различными системами контроля версий. Но эта книжка скорее описывает кнопочки и возможности среды программирвоания Eclipse. Примеры в ней чисто иллюстративные, чтобы хотя бы уловить смысл современных программистских технологий в Java.

Спасибо, поизучаю, JSF мне вполне нравится пока. Однако все равно интересно, где и когда используется EJB и где это оправдано и интересна его связка с JSF, например

. Ну нафик такую сложность.

ты протух, там щас ни капли xml, ну кроме конфига jpa

EJB в состоянии анабиоза, как и CORBA. Забей. Тренд на OSGi.

Возможно. А есть пруфы этой точки зрения? Было бы интересно.

Хорстман с JSF надо читать после чего-то, просто с наскока ничего непонятно.

//пытался прочитать сразу после второго тома его книги о Java SE

The Java EE 6 Tutorial уже предлагали?

Большей частью изучен, но просветления не наступило.

Enterprise JavaBeans 3.1 Andrew Lee Rubinger, Bill Burke

Вроде эта книга. Насколько помню рассказ своего знакомого - простая, понятная и хорошая книжка.

где и когда используется EJB и где это оправдано

по пунктам.

Где

в устаревшем софте.

когда

когда у заказчика много денег и ты помагаешь ему он них избавится.

оправдано

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

EJB стоит изучать, когда ты знаешь что это 100% тебе пригодится по работе, и изучать стоит за счет рабочего времени, иначе это мёртвое знание - без опыта и желательно многолетнего EJB никому не надо и уже давно.

Какие ваши доказапруфы?

Да лана, последние ejb от спринга уже мало чем отличаются.

“Объектов недостаточно. Нужно еще...”?

типичная статья с хабра: немного петросянства и никакого смысла

Это перевод, а не «статья с хабра».

очень аутентично смотрится на хабре, ибо таки петросянство и бессмысла.

тыб лучше чуваку рассказал почему компонентные stateful фреймворки типа jsf - очень плохо

почему компонентные stateful фреймворки типа jsf - очень плохо

Ты ничего не путаешь?

jsf - научился хранить состояния компонентов на клиентской стороне а не в http сессии?

В смысле? Данные формочек хранятся у клиента, пока он их не отослал.

срочно читай что такое JSF и что такое jsf компонент

а потом уже отвечай

Нужно бояться, что таймаут http-сессии истечёт, и клиенту нужно будет обновлять страничку с формочкой и заново набивать данные?

бгг, нужно боятся что при паре тыщ одновременных сессий тебе потребуется какойнить вшивый Power 595

в то время как таже логика но без этих сраных JSF (например на убогом GWT) будет крутиться на персоналке

JSF не применяют в хайлоад-проектах? Если нет возможности покупать дорогое ibm (c) железо?

хайлоад, вообще плохо сочетается с этим вашим javaee, но тыща сессий - ни разу не хайлоад, так шо уймись

я не фанатик жаваее, мне интересна сама информация.

AJAX используется как в JSF, так и в GWT. Так что логика персистентности данных одна и та же.

начни тогда с изучения концепций: сохранение состояния на клиенте и сохранение состояния на сервере.

Понятно что «идеальное» приложение которое хранит все на клиенте это будет сферический helloworld.

Когда разницу между концепциями освоишь, посмотри на корень проблемы: почему плохо большая сессия, почему плохо генерировать представление на сервере (и в каких случаях это плохо), почему представление «документа» в виде «компонентов» это плохо (тут камень и в GWT)

еще стоит почитать почему JSP - говно (и ASP тоже) и почему некоторые извращенцы юзают всякие там поделки (http://mustache.github.com/, например, способные рендерится как на сервере так и на клиенте, енимп на лоре что-то похожее пытаются использовать) вместо «заслуженых и энтерпрайзных технологий»

ну а когда ты все это увидишь, а потом увидишь что JSF - это эдакая куча недостатков всего указанного, то собственно вопросов не будет.

да иногда достаточно увидеть код какогонить приложения писанного индусамивдуше чтобы понять насколько плох JSP

ссылочки:

http://stackoverflow.com/questions/5474316/why-does-jsf-need-to-save-the-stat...

http://raibledesigns.com/rd/entry/why_the_bias_against_jsf

http://blog.brunoborges.com.br/2010/12/top-10-reasons-why-i-dont-like-jsf.html

http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/

и т.д. но это хрень которая гуглится, я ее не читал ибо «видел код»

Весь вой в основном касается JSF 1.0. Большая часть проблем решена в поздних версиях JSF 2.x.

единственное шо они могли решить - _частично_ хранить состояние компонентов на клиенте, а самый смак один фиг останется, ибо идея убога по своей сути

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

Вот еще ссылка с высокой концентрацией баттхерта на фоне использования JSF - http://ihatejsf.com/

Аффтар, не верь тем, кто говорит, что EJB - это сложно. Ну, точнее, это справедливо для 2.x, а EJB 3.1 - это очень просто (одна-две аннотации на бин). Советую прочитать туториал по Java EE 6, и вообще поизучать сайт оракла на эту тему, а все технологии с номерами версий меньше тех, что входят в Java EE 6, посылать лесом - тогда будет шанс не потерять разум и все-таки грокнуть ынтырпрайзную жаббу - она сейчас движется в правильном направлении, вбирая в себя правильные технологии.

Мне всегда казалось, что этот Tutorial то еще фуфло. Разве нет? Его достаточно, чтобы писать Java EE приложения?

Туториал дело хорошее, но там как-то очень поверхностно и примеры какие-то безжизненные.

Кстати, книга, отмеченная выше по JSF на рюсске языке оказалась действительно вполне сносной и даже неплохой.

Нет, конечно. Он нужен, чтобы ознакомиться с концепциями.

Поясните плз по-хардкору, когда EJB следует использовать и вообще когда оно используется?

когда EJB следует использовать и вообще когда оно используется?

http://docs.oracle.com/javaee/6/tutorial/doc/gipmb.html

Benefits of Enterprise Beans

For several reasons, enterprise beans simplify the development of large, distributed applications. First, because the EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container, rather than the bean developer, is responsible for system-level services, such as transaction management and security authorization.

Second, because the beans rather than the clients contain the application’s business logic, the client developer can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, the clients are thinner, a benefit that is particularly important for clients that run on small devices.

Third, because enterprise beans are portable components, the application assembler can build new applications from existing beans. Provided that they use the standard APIs, these applications can run on any compliant Java EE server.

When to Use Enterprise Beans

You should consider using enterprise beans if your application has any of the following requirements.

The application must be scalable. To accommodate a growing number of users, you may need to distribute an application’s components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients.

Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.

The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.