Требование использования DI и валидации бинов (JSR 303), в частности в JSF 2.0 имеет ряд следствий:
1. Валидация выносится из JSF в аннотации программных компонентов. Такими компонентами, скорее всего, должны быть Entity. И это явно делает Entity особым и специфическим компонентом присущим не только JPA или EJB.
2. Entity становятся не только носителями постоянной информации для JPA.  То есть, заставив валидацию на основе аннотаций работать однородным образом в JPA, и в JSF разработчики Java EE тем самым подталкивают использовать Entity и для приема информации из параметров запроса.

И возникает вопрос: почему они не идут дальше и не решают таким же образом конвертирование данных, что было бы вполне естественным шагом. В качестве упражнения я "расковырял" исходный код Hibernate Validator'а и "состряпал" по образу и подобию конвертор, Однако, чтобы оный конвертор использовать надо инициировать автоматическое конвертирование извращенным образом.

И все же,  я понять не могу - почему разработчики Java EE в принципе разобравшись с валидацией, остановились на пол пути. А может что-то в этом направлении делается, да я не знаю? Хотелось бы услышать Ваше мнение?

Никто мне так и не ответил. По ходу тут еще размышлял:
Вообще, по моему мнению, в архитектуре JSF имеется "бяка". Они как и ранний Starts пытаются написать интегрированный фреймворк для решения всех задач презентационного слоя. В результате архитектура фреймворка становится негибкой. 
Мне кажется фреймворки должны быть мелко гранулированы и специализированы, чтобы можно было из них, как из кубиков собирать архитектуру приложения. А интерфейс для их склеивания должны обеспечивать спецификации. Тот фреймворк, который претендует на универсальность и всеобщие  решения внушает подозрения относительно его будущего (Spring?).

Может кто-нибудь все же покритикует меня?

Это сообщение отредактировал(а) mbasil - 14.4.2011, 06:51

Критиковать не буду, а поддержу. И Spring и JSF слишком перегужены и сложны. Мой многолетний опыт позволяет мне отказаться от этих фрэймворков. Я их оцениваю очень низко. На 3 с минусом.

Спасибо за поддержку. 
То есть мне кажется будущее за небольшими специализированными фреймворками, которые будут выполняют четко фиксированный небольшой набор задач, очерченный кругом функционала фреймворка. И дело тут даже не в сложности, а в необходимости достижения гибкости архитектуры без потери производительности. Стремление к всеохвату в такой ситуации приводит к провалам. Вспомним только старые EJB 2.x и сравним с новым подходом для EJB 3.x.

Неа. Каждый такой фреймворк растет, пока не теряет популярности под собственной тяжестью. Так что будущее за "разжиревшими" фреймворками, которые сейчас специализированны. А потом за следующими такими же.

Примеры? Spring. Был DI, стал монстр, и сейчас народ потихоньку с него спрыгивает.
Пример из автомобильной области. Wolkswagen Golf с каждым поколением рос, рос, и в пятом поколении перерос им же открытый гольф-класс.

Классно!  Разработчики фреймворка видят, что он "жиреет", откусывает куски, которые не может проглотить, но ничего сделать не могут или не хотят. Даже под страхом смерти. EJB и Strats кажутся едва ли не единственными проектами, которые выплюнули то, что откусили.
Хотя Вы правы эта тенденция имеет место, и не только в автомобилестроении.
Однако думаю, что естественный отбор все расставит по местам.

эволюционные процессы медленны.

Альтернатива - стоять на месте, а это еще хуже. 

Ох, философия в чистом виде Конвертирование чего во что? И как оно соотносится с валидацией?
Какая бяка? Что в JSF не гибко? Он служит для быстрого ваяния страниц с помощью стандартный компонент и по-моему вполне справляется со своими задачами. Может ты просто не ту технологию выбрал? Тот же Spring MVC - это совсем другой фреймворк, там тебе нужно интерфейс самому рисовать с помощью HTML, JS. А Vaadin, ZK, GWT - это еще один тип фреймворков, которые отлично подходят для внутренних приложений и тех, где не нужна индексация. Я веду к тому, что может ты просто неверно выбрал инструмент, но сам инструмент-то от этого плохим не становится ;) 
Вспомнили. Сравнили. И? К чему ты вел? Что EJB теперь не охватывает все на свете? Что, уже нет никаких Session beans, entity beans, MDB, CMT, remote transactions? Да вроде все есть, просто они это сделали удобней, за что им большой плюс.
Spring - это не фреймворк, это набор фреймворков и библиотек, которые можно использовать как по отдельности, так и все вместе; кто с него начал спрыгивать и почему? С какого конкретного модуля спрыгивают и какой выбирают взамен? В моем окружении не замечаю такой тенденции. Да и все новинки стараются как-то интегрироваться со Spring. 
Вышел EJB 3, CDI, JPA, но это не значит, что все взяли и отказались от лидеров, да и вряд ли когда-то стандарты смогут набрать большую аудиторию, ибо они всегда будут отставать.Например? От Hibernate отказываются? Или от EHCache? Или от Apache Camel? Не сильно понимаю почему люди будут отказываться от того, что становится более функциональным (замечу, что более функциональное не значит более сложное, тот же Spring MVC стал со временем только проще). От библиотек/фреймворков отказываются скорей потому, что находятся более продвинутые альтернативы, которые вполне так могут и превосходить по функциональности и быть по-жирней. 
И снова громкие слова, но никакой конкретики. Что ты используешь взамен? Servlets API? 
Я не устаю повторять - у каждого инструмента есть своя ниша, и кривые руки не делают инструмент кривым.

Это сообщение отредактировал(а) Старовъръ - 14.4.2011, 23:27

Я согласен с этим утверждением. У "Инвалидки" тоже есть своя ниша. И у Запорожца. И у Москвича - тоже. Поэтому ты абсолютно прав.

C этим возражением согласен. Конкретизирую: я говорю про его начальную задачу, реализацию IoC.


Например, на Google Guice вместо Spring DI. За последний месяц на моих глазах одна команда выбрала его при разработке с нуля, а вторая решила выкинуть Spring (в части DI) и перейти на него.


Конечно, сейчас-то он на пике популярности. Вопрос в том, сколько еще продлится этот пик.


Да, от Hibernate в чистом виде - отказываются. Растет JPA, а какой провайдер его обеспечит - дело десятое. В своем последнем маленьком проекте я тоже поменял Hibernate (хотя это и не сильно показательно - мне был важен размер подключаемых библиотек, которй редко кого волнует).
Насчет остальных твоих примеров не скажу, потому что применения их вокруг себя не видел.

Это сообщение отредактировал(а) batigoal - 15.4.2011, 07:02

to Старовъръ

1. Речь идет о конвертировании из строки символов в свойство бина, и обратно. В JSF валидация и конвертирование задействованы похожим и однородным способом.
Вдруг появляется JSR 303, где валидация рассматривается как отдельное действо, описанное с помощью аннотаций. То есть валидаторы приписываются не страничным UI компонентам, а свойствам Entity. Hibernate также может использовать эти валидаторы, например, @NotNull. Впрочем, и приложение Java SE вполне этим механизмом может воспользоваться. Чувствуете, чем пахнет? Механизм проверки значения свойства становится унифицированным и выносится в отдельные классы – валидаторы. Однако всем нужно и конвертирование «строка-свойство-строка», то есть всем нужны конверторы. При работе со Swing тоже. А также при создании разнообразных отчетов, а не только с HTML. Так что оно само напрашивается обеспечить конвертирование  «строка-свойство-строка» таким же образом, как валидацию. Это не философия, а техника. 

2. JSF валидацию типа JSR 303 принял. Но если они и конвертирование выдернут, то возникает вопрос – по какому праву у них перемешалась работа MVC, в частности контроллера с презентационными UI элементами. Вот хочу я использовать свой контроллер и ихние  презентационные страничные компоненты, ан не тут то было. Хоть навигация с работой собственно презентационных страничных компонентов напрямую не связана, они все мешают в одном котле. Вопрошаю риторически, а как же пропагандируемый SUN “loosely-coupled approach”. То есть вы при разработке “слабо связывайте”, а мы при создании фреймворков все будем так смешивать, чтобы отодрать было нельзя – а то чужой дядя всунется.

3.

Об этом то и речь. SUN пишет буквально «JSP устарели – используйте JSF». Замечательно, но вот не могу я взять реализации MVC Spring или свою реализацию MVC и соединить со страничными компонентами JSF. То же с конверторами. Либо реализуй наш  интерфейс Converter, либо пошел вон. 

4. И еще раз подчеркну – Entity изменяются. Они не только для JPA. Они есть носители информации и аннотаций. Вынесли валидаторы наружу, но привязали аннотациями к Entity, То же самые отношения должны быть в связке Entity – конвертор. А во что конвертировать это смешной вопрос. Обычно в строку, на которую мы любим смотреть и редактировать, а также передавать в HTTP, XML или Json, а завтра хоть в черта, главное, что без конвертирования не обойдешься. Это не менее актуально, чем валидация. 

5. Главное изменение в EJB 3.x это скорее не упрощение работы, а выделение Entity и работы с базой в отдельную епархию.

5. Зря вы так о стандартах. Они есть сконцентрированный опыт, возможность обеспечить тот самый “loosely-coupled approach”. В чем основная сила Java? В сообществе разработчиков. А стандарт это продукт сообщества. Слабое связывание дает возможность заменять элементы архитектуры, каковыми являются фрейворки – возможность выбора. 


Это сообщение отредактировал(а) mbasil - 15.4.2011, 12:04

Ткни меня носом где в JSP есть конвертирование свойств в строки. Или ты это так называешь EL?
Как по-твоему коррелируют валидация и конвертирование? Это вовсе разные вещи, даже приблизительно не стоят вместе. Если тебе интересна конвертация объектов в другие, посмотри на Apache Dozer.
Во-первых, MVC бывают разные. Во-вторых, никто там ничего не перемешивает: есть страница, есть обработчик событий (контроллер), никакого смешивания.
Эм.. это где такое написано? Есть дерзкие подозрения, что ты это сам придумал.

mbasil, у меня складывается впечатление, что ты о чем-то услышал и, не допоняв, решил высказать свои мысли. Так любят бахвалиться знаниями люди, которые только что для себя открыли что-то новое. Так вот, дабы не казаться голословным максималистом, попробуй сначала разобраться в предмете, обдумать его хорошенько, прожевать и проглотить, а потом можно начинать делать свои заявления, учить других; но никак не раньше. Только предупрежу, что на это уходит как правило много времени, у каждого по-разному. 
На "чистом" JPA далеко не выедешь, как правило его не хватает и используют implementation dependent механизмы. А вообще XML based approach в Хибе рулит, он и выглядит симпатичней (это правда субъективно), и возможностей предоставляет чуть больше.
Да, я вот тоже заметил, что форумы прям обвешаны вопросами по Guice, он за 4 года своего существования все больше и больше набирает популярность  

1. Конвертирование строк в некоторые значения программных компонентов (и обратно) это типичный вопрос ВСЕХ современных приложений, и если ты этого не заметил, тогда и смысла нет пикироваться. 

2. По поводу типичного поведения механизмов валидации и конвертирования еще раз повторю. Я же говорил, что ради эксперимента просто аналогично Hibernate Validator написал аналогичный Converter. Причем протестирвоал его как требуется. А раз это возможно, значит валидаторы и конверторы могут И ДОЛЖНЫ работать однородно.

3. Тот факт, что SUN декларирует буквально «JSP устарели – используйте JSF» это я не сам придумал, а прочитал в их курсе.

4. Да не хочу я бахвалится, я хочу, чтобы мы все ВМЕСТЕ понимали современную тенденцию. Я пишу и подчеркиваю мысль о том, что Entity принмают особую роль "носителя аннотаций" и переносчика данных. О том, что Entity становятся "управляемыми компонентами" с точки зрения JSF, что стоит подумать, как  сделать Entity универсальным носителем информации в приложении, а Вы пытаетесь уличить меня в неграмотности или попытке завоевать репутацию негоднвми средствами. Я то считал эту мысль основной в своем вопросе, но никто этого не заметил.

5. На форуме общаются профессионалы. Разве нет выгоды в том, чтобы, анализируя поток современных изменений, принимать правильное решение. Недавно в части гуманитарной я услышал мнение, что "мейнстрим" всегда ошибочен. В том смысле, что новое всегда опровергает мейнстрим. Это не совсем так, но и утверждение типа: «Spring всегда прав»  из области - я не хочу думать.

6. "Чистого" JPA не существует, оно изменяется от версии к версии. В "чистом" JPA имеется много недоработок, в частности, нет даже позыва обращаться к хранимым процедурам. Есть и масса других недоработок. Однако это не означает, что надо полностью отрицать JPA, а означает, что мы должны воздействовать на его разработчиков с целью усовершенствования.

Добавлено через 8 минут и 33 секунды
Кстати мысль о том, что не всегда надо использовать JPA совершенно правильна. Есть задачи,  в которых просто необходимо использовать  сервлеты и прямое JDBC. И это никак не противоречит использованию  JPA для основной массы операций с базой данных - всякому овощу свое время. Напоминаю, что мой вопрос был посвящен общей тенденции и я пробовал согласовать с Вами свои наблюдения о ней.

См. выше - примеры я привел не из форумов, а из своего личного окружения. Понятно, что на форумах правит мейнстрим.