|
|
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
funikovyuriНу так выражайтесь яснее... а то несколькими постами выше заявляли что так относитесь ко всем стандартам. Ну, так читайте весь трид а не отдельные предложения. Все стандарты замедляют развитие это раз. Стандарты до реализаций это зачастую зло - два. Конкретно J2EE спецификация имеет в себе целый ряд недоработок это три. funikovyuriОтлично, одна есть. Как любитель hibernate я думаю EJB3.0 тоже должны были приветствовать. И метод #lock() при всем уважении погоды тут не делает. Просто у меня уже нет никакого желанию копать EJB3 персистенс глубже после того что я вижу там нет нормально реализации пессимистичного лока. Я уверен кто уже начал писать крупный проект, может поделится остальными граблями. Использовать же весь EJB3 тоже нет желания во-первых из-за ограниченной облати классов где работает инжекция, во-вторых из-за вездесущих аннотаций которые перегружают код. А так же показывают чудеса отсутствия гибкости в ряде ситуаций. funikovyuriЕсть еще JavaMail, JCA и т.д. http://java.sun.com/javaee/technologies/ JavaMail достаточно убогое API, но все по привычке пользуются потому что альтернатив-то и нет. То же самое как с сервлетами. Разобратся их ещё можно до ума доводить ого-го. JCA кто-то реально в проектах пользует? funikovyuriДействительно неудачной вещью были только EJB < 3 - но это проблема не стандартов как таковых, а вообще архитектуры которую тогда считали правильной. Как по мне EJB3 с JSF точно такая же неудача. funikovyuriНельзя делать выводы о вреде стандартов только на основе примеров типа spring и hibernate. Ой, можно подумать все мои утверждения выше только об этих двоих. Не надо мне приписывать то чего нет. Выше я уже привел так же ряд аргументов не имеющих отношения к этим двум решениям funikovyuriКроме них, единственный путь который я знаю - это путь MS - он imho базируется на 2х вещах - 1. никогда не идти по непроверенному пути(т.е. никогда ничего не изобретать) 2) периодически начинать с нуля. Мне такое решение не нравиться намного больше чем некоторый overhead с открытыми спецификациями. Opensource уже давно двигает Java гораздо больше J2EE. Если бы не opensource .NET бы уже отхватил гораздо большую порцию рынка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 17:17:04 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
авторOpensource уже давно двигает Java гораздо больше J2EE. Если бы не opensource .NET бы уже отхватил гораздо большую порцию рынка. Ну не знаю куда и кого он двигает... Opensource - это типа как игра жизнь - эволюция, которая не думаю развивается во всех направлениях сразу. Делать на него основную ставку нельзя, должен быть существовать процесс подводящий итоги и/или направляющий. Imho Java вперед двигает именно стабильная и удобная базовая платформа. Используя java люди могут быть относительно уверенны в том что их решения не будут выброшены на следующий день по независящим от них причинам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 17:37:42 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
Java поэтому и является очень удобной, потому что в ней достаточно равновесно учатствуют и opensource и разработчики стандартов-спецификаций. И если вглядеться, то эти направления постоянно стимулируют друг друга. Например разработчику Spring надоели ejb 2.x и он решил написать свое решение. Но идея IoC в самой простой реализации в ejb 2.x уже была, Род Джонсон сильно углубил и развил эту идею + создал классную архитектуру. Теперь идет обратный процесс, разработчики стандарта берут многое за основу из opensource. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 18:04:37 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
BlazkowiczТак вот. Взять к примеру какой-нить метод. EntityManager.lock. Я вот знаю, в случае хибера он ложиться на хибернейтовский метод lock который делает SELECT FOR UPDATE. Но теперь я хочу портировать своё приложение с JBoss на Oracle AS. И скажи мне с пол пинка. Что буде происходить на TopLink с вызовом "стандартного" метода EntityManager.lock? А если чур в TopLink не заглядывать а попытатся разобратся по спецификации и EntityManager API doc? Вот это-то и называется, здравтсуй жпа - новый год. Ты не знаешь что там реально происходит. И не сможешь угадать. И не сможешь предсказать заработает ли этот метод при переезде на другой сервер как тебе надо или нет. Насколько я понимаю, вам не обязательно знать, какая реализация lock имеется у hibernate или toplink. Разве важно какими методами будет сделан этот самый лок? Главное чтобы результат соответствовал заявленному в спецификации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 18:26:21 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
seacatНасколько я понимаю, вам не обязательно знать, какая реализация lock имеется у hibernate или toplink. Разве важно какими методами будет сделан этот самый лок? Главное чтобы результат соответствовал заявленному в спецификации. EJB2 CMP потому и сдохли что никто не знал что на самом деле происходит в базе. А знание того что происходит в базе это сильное подспорье в борьбе за производительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 19:03:47 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
Blazkowicz funikovyuriНу так выражайтесь яснее... а то несколькими постами выше заявляли что так относитесь ко всем стандартам. Ну, так читайте весь трид а не отдельные предложения. Все стандарты замедляют развитие это раз. Стандарты до реализаций это зачастую зло - два. Конкретно J2EE спецификация имеет в себе целый ряд недоработок это три. funikovyuriОтлично, одна есть. Как любитель hibernate я думаю EJB3.0 тоже должны были приветствовать. И метод #lock() при всем уважении погоды тут не делает. Просто у меня уже нет никакого желанию копать EJB3 персистенс глубже после того что я вижу там нет нормально реализации пессимистичного лока. Я уверен кто уже начал писать крупный проект, может поделится остальными граблями. Использовать же весь EJB3 тоже нет желания во-первых из-за ограниченной облати классов где работает инжекция, во-вторых из-за вездесущих аннотаций которые перегружают код. А так же показывают чудеса отсутствия гибкости в ряде ситуаций. funikovyuriЕсть еще JavaMail, JCA и т.д. http://java.sun.com/javaee/technologies/ JavaMail достаточно убогое API, но все по привычке пользуются потому что альтернатив-то и нет. То же самое как с сервлетами. Разобратся их ещё можно до ума доводить ого-го. JCA кто-то реально в проектах пользует? funikovyuriДействительно неудачной вещью были только EJB < 3 - но это проблема не стандартов как таковых, а вообще архитектуры которую тогда считали правильной. Как по мне EJB3 с JSF точно такая же неудача. funikovyuriНельзя делать выводы о вреде стандартов только на основе примеров типа spring и hibernate. Ой, можно подумать все мои утверждения выше только об этих двоих. Не надо мне приписывать то чего нет. Выше я уже привел так же ряд аргументов не имеющих отношения к этим двум решениям funikovyuriКроме них, единственный путь который я знаю - это путь MS - он imho базируется на 2х вещах - 1. никогда не идти по непроверенному пути(т.е. никогда ничего не изобретать) 2) периодически начинать с нуля. Мне такое решение не нравиться намного больше чем некоторый overhead с открытыми спецификациями. Opensource уже давно двигает Java гораздо больше J2EE. Если бы не opensource .NET бы уже отхватил гораздо большую порцию рынка. Вот Вы так ругаете Java EE и другие стандарты. А что же Вы используете в реальных проектах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 20:25:45 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
Blazkowicz EJB2 CMP потому и сдохли что никто не знал что на самом деле происходит в базе. А знание того что происходит в базе это сильное подспорье в борьбе за производительность. Согласен. Поэтому в JPA вы можете выбирать реализацию и этот выбор никак не связан с апп сервером. У нас сейчас на вебсфере используется toplink essential, но легко подставляется реализация от hibernate (проверяли, работает). Исходники, как известно, у обеих реализаций открыты. Так что JPA достаточно хороший стандарт, отвязывающий от конкретной реализации orm. А вот с IoC в ejb3 действительно слабоват и пока альтернативы Spring нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2007, 20:25:58 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
seacatПоэтому в JPA вы можете выбирать реализацию и этот выбор никак не связан с апп сервером. У нас сейчас на вебсфере используется toplink essential, но легко подставляется реализация от hibernate (проверяли, работает). Исходники, как известно, у обеих реализаций открыты. Так что JPA достаточно хороший стандарт, отвязывающий от конкретной реализации orm. Абсолютно не согласен. На кой использовать урезаную версию API к хиберу, когда он предоставляет гораздо более широкие возможности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2007, 13:19:23 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
BlazkowiczАбсолютно не согласен. На кой использовать урезаную версию API к хиберу, когда он предоставляет гораздо более широкие возможности? Да по той же причине, по какой вы используете ограниченные возможности хибера, а не более широкие jdbc: отвязка от конкретной реализации orm и возможность выбора. Более того спец. возможности конечно используются, но только через wrapper. В случае смены реализации нужно будет переделать только wrapper, а не все те части кода, где используется orm. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2007, 14:17:53 |
|
||
|
Struts vs JSF vs Spring
|
|||
|---|---|---|---|
|
#18+
seacatДа по той же причине, по какой вы используете ограниченные возможности хибера, а не более широкие jdbc: отвязка от конкретной реализации orm и возможность выбора. Более того спец. возможности конечно используются, но только через wrapper. В случае смены реализации нужно будет переделать только wrapper, а не все те части кода, где используется orm. Какие-то не правомерные аналоги. JDBC тут причем? ORM это следующий уровень, а не как ни кастрированый API от JDBC. Вот EJB3 как раз и есть кастрированый API от Hibernate. А излишняя абстрагированность от всего ещё никому на пользу не пошла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2007, 16:19:56 |
|
||
|
|
start [/forum/topic.php?fid=59&startmsg=34456888&tid=2146057]: |
0ms |
get settings: |
15ms |
get forum list: |
26ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
60ms |
get topic data: |
21ms |
get forum data: |
6ms |
get page messages: |
99ms |
get tp. blocked users: |
3ms |
| others: | 278ms |
| total: | 518ms |
| 0 / 0 |
