| 0
- 06.06.2012 - 15:19
|
Господа, прослушал тут подкаст про миграцию приложений с Spring на JavaEE 6 (https://blogs.oracle.com/javaspotlig...e_85_migrating). Кому лень слушать, могу сказать, что суть в том, будто сейчас JavaEE такая няша, что в Spring'e нет никакого смысла. Перечисляются достоинства JavaEE и рассказывается, что путем поэтапной замены кода можно полностью перейти на JavaEE. Воодушевленный, я открыл один из своих старых Spring-проектов - и тут же возник вопрос: а чем из JavaEE-стека можно заменить SpringMVC? У кого-нибудь есть подобный опыт миграции? Что заюзать вместо SpringMVC? Я пока смотрю в сторону JSF, но это немного не то.     | |
| 1
- 06.06.2012 - 22:32
|
Немного философии: Цитирую одного махрового товарища http://russian.joelonsoftware.com/Ar...AndMotion.html Когда я был израильским десантником, один генерал заглянул к нам чтобы произнести небольшую речь о стратегии. В пехотных сражениях, говорил он, существует лишь одна стратегия: огонь и движение. Вы движетесь в сторону врага, одновременно ведя огонь. Ваши пули вынуждают его залечь, и в это время он не может стрелять в вас. <...> Движение позволяет вам завоевывать территорию и приблизиться к врагу, где ваши пули достигнут своей цели с большей вероятностью. Если же вы не движетесь, враг начинает понимать что происходит - и это плохо для вас. Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь. Я запомнил это надолго. <...> Мне потребовалось ещё пятнадцать лет чтобы понять, что принцип "огонь и движение" действует и в обычной жизни. Необходимо ежедневно продвигаться вперёд, хотя бы на немного. Не имеет никакого значения что ваш код уродлив и содержит много ошибок, и никому он не нравится. Если при этом вы двигаетесь вперёд, - пишете код и постоянно исправляете ошибки - время на вашей стороне. Будьте начеку когда конкуренты ведут по вам огонь. Может они всего лишь хотят вынудить вас тратить всё ваше время отвечая на их залпы, так чтобы вы не могли продвигаться вперёд?! Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей. Посмотрите получше на ландшафт индустрии программного обеспечения. Компании, которые можно назвать успешными - это те, кто меньше всего зависят от монстров рынка программного обеспечения и не вынуждены тратить всё своё время догоняя лидеров, переписывая код и исправляя ошибки, возникающие только в Windows XP. Менее успешные компании - это те, кто тратит слишком много времени ловя каждое движение Microsoft, гадая в каком направлении она пойдёт дальше. Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет. Длинновато вышло, и не про яву (хотя автор пишет и про javaee), но суть надеюсь ясна. Зачем переходить с одного поделия в виде SprinMVC на другое JavaEE? | |
| 2
- 06.06.2012 - 23:42
| 1-wayerr >..с одного поделия в виде SprinMVC на другое JavaEE? Слово "поделие" несколько уничижительно звучит.. Ты используешь что-то третье для разработки веб-приложений на Java? 1-wayerr >Зачем переходить Тогда все же предлагаю послушать подкаст ;) | |
| 3
- 07.06.2012 - 21:36
|
>Слово "поделие" несколько уничижительно звучит.. ну я покуда не увидел преимуществ завязывания на такие вещи как спринг. >Ты используешь что-то третье для разработки веб-приложений на Java? у нас используется системы вида naked objects и собственные наработки, потому что для вышеуказанного типа систем удовлетворительных готовых решений не нашлось. Посему и спринг и javaee мне одинаково не подходят и я их не использую. >Тогда все же предлагаю послушать подкаст ;) да я и без подкаста предпочту javaee спрингу, хотябы потому что там у меня есть альтернативы - одно решение от вендора не работает, можно выбрать другое. | |
| 4
- 17.06.2012 - 13:27
| 3-wayerr > А можете вкраце описать что у вас за задача такая, под которую не Spring, не J2EE не подходит? Очень интересно. | |
| 5
- 17.06.2012 - 22:35
|
а у нас объект предметной области != объект класса иначе говоря объекты (предметной области) имеют более высокий порядок, как следствие классы этих объектов могут создаваться в рантайме (основная задача платформы). Ну и все это под соусом naked objects. с этого начинается пляска - jpa в этом случае вырождается в key-value хранилище, или не будет динамики, да и вся инфраструктура jee и spring перестает приносить пользу, одни косяки 8) А добавлять в зависимости этих "монстриков" ради di и оберток над jdbc - слишком жирно. Да, сначала использовался di из jee и mdb, но позже "а ваша платформа требует jee контейнер? а у нас томкат и машинка старенькая!" в итоге jee был оперативно выпилен. | |
| 6
- 17.06.2012 - 22:37
| да, был както сварганен на базе jpa и dojo легкий движок с темже паттерном, есесно для любых изменения всю систему надо пересобирать 8), но в целом идея для небольших задач весьма удобная, один косяк - развивать движок некому. | |
| 7
- 18.06.2012 - 04:09
| 5-wayerr >а у нас томкат и машинка старенькая! http://openejb.apache.org/ | |
| 8
- 18.06.2012 - 10:41
| проще выкинуть чем совокупляться с процессом совокупления томката и сего. | |
Интернет-форум Краснодарского края и Краснодара |
