http://www.theserverside.com/books/wiley/masteringEJB/index.tss
Больше ничего не надо. Правда плохо то, что там все отвлечено от конкретного контейнера, поэтому последние 5% в каждом примере за тобой
Но при усидчивости пробьешь | Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Подскажите Хороший тутор |
| Автор: Zandr 24.5.2005, 06:38 |
| Так чтобы дней за 5 постигнуть философию Entity (CMP, BMP, если можно, в связке с hibernate), Session (Stateless, Statefull) и MessageDriven (или как там они) Beans. Можно конечно и яндексом и гуглом, но на отделение зерен от плевел, боюсь, уйдет непозволительно много времени, а нужно начать уже вчера. Вот такая вот засада... Есть у кого что на примете? |
| Автор: Domestic Cat 24.5.2005, 06:45 |
| Есть конечно. http://www.theserverside.com/books/wiley/masteringEJB/index.tss Больше ничего не надо. Правда плохо то, что там все отвлечено от конкретного контейнера, поэтому последние 5% в каждом примере за тобой Но при усидчивости пробьешь |
| Автор: Zandr 24.5.2005, 07:04 |
| ух, в какой уже раз выручаешь |
| Автор: tux 24.5.2005, 07:24 |
| И еще с привязкой к контейнеру (JBoss) - http://docs.jboss.org/jbossas/jboss4guide/r3/html/. Глава 11 про CMP-бины, глава 13 - про интеграцию с Hibernate. Где-то читал, что в JBoss собираются контейнер CMP сделать на основе Hibernate, но кажется до этого дело еще не дошло. |
| Автор: Zandr 24.5.2005, 09:15 |
мля!!! 840 страниц..... Код примеров в архиве - 5.3 метра... Как раз на 5 дней ....  |
| Автор: Domestic Cat 24.5.2005, 09:18 | ||
Тебе нужно около половины, из них начало - общие рассуждения |
| Автор: AntonSaburov 24.5.2005, 12:19 |
| Мне вообщем-то понравился тутор на SUN - http://java.sun.com/j2ee/reference/docs/index.html |
| Автор: Stampede 24.5.2005, 21:26 |
| Zandr, а ты уверен, что тебе нужны EJB? Просто в подавляющем большинстве проектов, построенных на EJB, использование EJB вообще не оправдано. Все приеимущества, которые как бы приносит эта технология, являются на поверку мнимыми и/или за них приходится платить страшную цену в виде кошмаров конфигурирования, отладки, плохой сопровождаемости и пр. Чтобы не быть голословным, назову эти якобы преимущества:
Так вот, за исключением буквально единиц проектов с тысячами транзакций в секунду, где действительно нужна масштабируемость, и по этой причине - распределенность (чтобы компоненты могли молотить на разных компах), во всех остальных случаях применять EJB - это типа как стрелять из пушки по воробъям. Поэтому если ты хочешь просто для себя разобраться в идеологии EJB, то, разумеется, почитай те книжки, которые тебе порекомендовали, но если речь идет о проектировании системы, которую именно тебе предстоит разрабатытвать и сопровождать, то очень советую для начала прочитать книжку Рода Джонсона "J2EE Development Without EJB". Там очень хорошо расписано, почему EJB - это плохо, и для всех сфер их применения предлагаются более "легкие" альтернативные решения. Скачать можно со страницы, на которую давал ссылку Souljah и Котъ: http://java.fpestde.net/ |
| Автор: batigoal 24.5.2005, 21:48 |
| Stampede Не мог бы ты вкратце перечислить альтернативы, если помнишь? |
| Автор: Stampede 25.5.2005, 19:51 | ||
Боюсь, вкратце не очень получится, но я все же постараюсь. Короче, Род Джонсон - это Java писатель, архитект и активный участник опен-сорс движения. В качестве последнего он возглавляет разработку Spring - легкого (lightweight) контейнера, который на самом деле является более фреймворком, чем контейнером - смотря с какой стороны смотреть. У него есть уникальное (уникальное больше в своей целостности, потому что сами по себе отдельные идеи как бы не сильно новы) видение архитектуры J2EE приложения, основанное на приличном опыте разработки больших проектов. И вот нахлебавшись горя с EJB, он выносил под сердцем свою собственную концепцию и реализовал ее в виде Spring'а. При этом он написал две книжки, J2EE Design and Development и J2EE Development without EJB. Первую я видел только в виде оглавления. а вторая лежит у меня на работе, и когда мне хочется отвлечься от грустных мыслей о несовершенстве этого мира, я просто открываю ее и улетаю парить вслед за мыслью автора, до того складно задувает, подлец Книжки во многом пересекаются, и главная мысль там сквозит примерно такая: Люди, очнитесь, не надо идти за мейнстримом, не надо слепо юзать EJB только потому, что оно существует - и подробнейшим образом аргументирует свою позицию. Я его книжку воспринял всей душой, потому что она удивительно тонко резонирует в такт моим собственным мыслям по этому поводу. Причем моему самомнению льстит то обстоятельство, что я все это видел и осознавал еще года четыре назад, когда по поводу EJB была только одна всеобщая эйфория, причем не имея ни малейшего опыта практической работы с EJB - чисто умозрительно. Говоря о Спринге: ключевыми словами к пониманию идеологии Спринга являются:
В понятие легковесности он вкладывает не столько скромность к ресурсам (хотя и это тоже), сколько способность технологии быть non-invasive, то есть оказывать как можно меньшее влияние на архитектуру приложения, быть по возможности прозрачной. Например, EJB - это очень, просто охерительно инвазивная технология. Если ты пошел по пути EJB - все, ты отдал всю свою свободу. Все твое приложение будет состоять из кучи EJB. Как нельзя быть немножко беременной, так и приложение не может быть немножко EJB. Это подход по принципу все или ничего. Далее, второй ключевой концепт: инверсия управления. Тут речь идет о том, что надо перестать думать о приложении в терминах понятий, навязываемых тебе технологией, а думать о нем как о наборе простых человеческих классов и компонентов, которые наилучшим образом отвечают прикладной области этого приложения - то, что называется POJO (plain old Java objects). Но прикол с POJO заключается в том, что там существует много зависимостей одних компонентов от других, причем подчас бывает довольно трудно уследить, что в каком порядке должно инициализироваться и т. д. В Спринге эта проблема решается посредством механизма, который называется Dependency Injection. Заключается это в том, что ты как разработчик описываешь эти зависимости в файле конфигурации и потом можешь просто об этом забыть - Спринг разрешит все зависимости за тебя. У меня, честно говоря, смешанные чувства по поводу этого подхода, потому что я очень, просто органически не переношу кодировать в XML. Я лучше десять раз запрограммирую, чем один раз сконфигурирую. Но многим нравится, так что, может, что-то в этом есть. И третье, AOP. Ну, это для меня совсем новое понятие, я еще не очень понимаю, в чем от него кайф. То есть на пальцах это примерно так: ООП это очень здорово, но бывают моменты, когда ООП не сильно может помочь - это когда нужна служебная функциональность, которая логически идет поперек твоей вертикальной классовой иерархии: например, служба логирования, или контроль доступа, или управление транзакциями. Тогда ты как-то там это программируешь отдельно, а в нужных местах, где это будет использоваться, вставляешь указание на то, где это должно перехватываться и выполняться. Это может делаться через кодогенерацию. через модификацию байткода на этапе компиляции или, как это сделано в Спринге, на этапе выполнения. А теперь о тех альтернативах EJB, которые предлагает автор. Тут сразу надо отметить, что будучи активным продвигателем своего Спринга, он все в конечном итоге сводит к Спрингу, хотя реально в нем нет реализаций отдельных служб, а есть только слои абстракции. 1. Персистенция Предлагается выбор из Hibernate, TopLink или другого O/R средства, или JDO. Во избежание попадания в зависимость от конкретного производителя, рекомендуется пользоваться интьерфесом, предоставляемым Спрингом. 2. Управление транзакциями JTA, или в простых случаях просто JDBC координация, опять же через слой абстракции Спринга. 3. Удаленность RMI, SOAP, плюс он очень рекомендует проприетарные протоколы от Caucho: двоичный Hession и хмл'ный Burlap. 4. Пулинг ресурсов Предлагает внешние библиотеки типа Apache Commons Pool. 5. Управление доступом Показывает то, до чего мне в свое время пришлось доходить самостоятельно: что JAAS и декларативное управление доступом - это неработающая вещь. Как выход - предлагает реализовывать управление доступом средствами AOP. 6 Синхронизация потоков То, чего в EJB как бы вообще нет (в смысле как в анекдоте про монгольского космонавта: будешь лезть куда не следует, получишь по рукам). А синхронизировать - бывает надо. Для этой цели можно например использовать широко всеми используемую библиотеку синхронизационных примитивов Дага Ли (Doug Lea). 7. Асинхронная обработка Вот тут, говорит, звиняйте, братцы - чего нет, того нет. Не придумали пока ничего взамен Message Beans. Хотя, говорит, если сильно невмоготу, можете пока пользовать JMS в чистом виде, а там что-нибудь придумаем. Вот так вот примерно, если в нескольких словах. Хотя сам я, признаться, Пастернака не чител, в смысле Спринг не юзал - сужу только по книжке |
| Автор: batigoal 25.5.2005, 20:04 |
| Гут. Спасибо. |
| Автор: Chinook 25.5.2005, 21:16 | ||
Он, конечно, перец крутой и может себе позволить пофантазировать, но нам, простым смертным, этого делать нежелательно. Что я имею ввиду? Я имею ввиду принцип "20х80", т.е. 20% проектов приносит 80% денег. А именно: с ejb работают фирмы, которым как раз и нужна масштабируемость и распределенность, а это консалтинговые фирмы типа IBM, банки, телекоммуникации и т.п. Для них 2 -16 млн транзакций в час - норма, а там уже Hibernate не работает. И попробуйте менеджеру из IBM сказать что-то про Hibernate - он отправит вас в отпуск на лечение нервов. А именно в больших конторах и платят программистам, а там, где пишут "интернет-магазины" - слезы вместо з/п. Если идти дальше с работой в больших конторах, то можно сказать - забудьте вообще про способ реализации работы с БД. Почему? Потому что в большой конторе слой работы с БД находится хрен знает где (в Гон-Конге каком-нибудь) а вы через soap будете передавать запросы и команды, возможно, совсем не в sql. P.S. Это я злюсь на свою маленькую контору  |
| Автор: batigoal 25.5.2005, 21:21 |
| У меня тоже контора маленькая, но про работу с БД и я уже забыл. Промежуточный слой можно организовывать и без Hibernate. |
| Автор: 3,14 26.5.2005, 09:30 |
| Chinook Конечно без EJB в серьёзных проетах не обойтись, но это не значит что нужно отказываться от таких вещей как Hibernate, другое дело что в таких фирмах как IBM есть свои реализации подобных вещей. |
| Автор: Zandr 27.5.2005, 08:07 |
Какой интересный вопрос я задал, получается...  Просто устраиваюсь на работу, велено знать EJB, hibernate. Решения относительно того, на чем реализовывать проект будут приниматься не мной. По крайней мере в ближайшее время. Так что пока лучше просто хорошо делать своё дело. А за рекомендации спасибо - буду вникать |
| Автор: sandello 17.8.2005, 05:54 |
| В продолжение темы: что господа программисты/разработчики скажуть по EJB3? |