Обзор технологий

 
 
 
Сообщения:10007
На данный момент существует множество технологий в Java мире, часто очень тяжело определится что же использовать. Данная тема создана для того, чтоб внести ясность в этот пестрый мир. Но прежде всего хотелось бы сказать следующее: многие попробовав тот или иной инструмент, стараются выразить свои мнения в духе "нет, это плохо, потому что.. " или "о, это хорошо, потому что...". Так вот здесь нет места таким мнениям. Я не устаю повторять, что всякий инструмент имеет свою нишу, кривые же руки не делают сам инструмент кривым. Конечно, если совсем неприятные наработки, но они не набирают популярность как правило, поэтому и обсуждаются очень редко. Итак, здесь мы будем говорить о том, какая технология в каком случае подходит.
  • Database access
    • JDBC - в чистом виде используется не часто, потому как приходится писать очень много glue-кода, обычно реализовать проект с помощью JDBC довольно сложно и громоздко. Однако именно он поможет, когда вы захотите написать свой ORM ;) Также, JDBC довольно простой в использовании и не вынуждает вас тратить месяцы на его изучение. Работая с помощью JDBC вы имеете полный контроль над происходящим и соответственно максимальные возможности по тюнингу, что может помочь если у вас приложение очень высоконагруженное. С другой же стороны, вам придется писать SQL руками, вызывать его, работать с ResultSet'ами, самостоятельно реализовывать кеширование, маппинг ваших классов на реляционную модель (разные отношения: many-to-many, one-to-many, inheritance), кеширование на нескольких уровнях, поэтому стоит подумать трижды прежде чем писать приложение на чистом JDBC.
    • iBatis/MyBatis - это надстройка над JDBC, которая делает за вас часть работы - она из ResultSet строит объекты. То есть сделали вы запрос к БД, указали какие поля в какие классы должны мапиться, а собственно сам процесс происходит за сценой. Этот фреймворк полезен, когда важна производительность, потому как вы сами будете создавать запрос к БД. Разработка с помощью iBatis происходит намного быстрей, чем с чистым JDBC, поэтому чаще всего, когда у вас стоит вопрос в производительности, но и скорость разработки тоже важна, то данный фреймворк - это то, что вам нужно. Из недостатков опять же - нужно самому писать и поддерживать схему БД и SQL. Фреймворк довольно прост в изучении
    • ORM (object/relational mapping) - это фреймворки, которые позволяют совсем отгородится от реляционной БД, вы мапите объекты на схему БД, а затем просто говорите "сохрани сей объект" и он сохраняется без написания родных SQL команд.
      ORM освобождает разработчика от многих обязанностей: работу с разными связями объектов на уровне реляционной БД, написание SQL команд, поддержание разных скриптом для разных СУБД если это требуется, как правило подключить кеширование к ORM'у очень просто, ничего самому делать не нужно, ну и в общем количество кода, который нужно написать, становится намного меньше, что улучшает читабельность проекта и его поддержку.
      Бывает, что ORM'ы работают быстрей, например, вы знали, что кеширование подготовленных запросов в DB2 JDBC Driver значительно повышает производительность, а в InterBase JDBC Driver наоборот - серьезно бьет по производительности? Вы знали, что в некоторых СУБД обновление только измененных колонок записи быстрей, а в других - медленней? ORM'ы это знают.
      Однако вы должны понимать, что работа напрямую с SQL может быть как минимум такой же эффективной, то есть чаще всего вы можете написать запрос или такой же по эффективности, или лучше. Это значит, что в общем ORM будет проигрывать приложению на том же JDBC или MyBatis. Еще одним недостатком ORM'ов является их сложность, чтобы ими пользоваться эффективно, нужно хорошо в них разобраться, что как правило занимает много времени (хотя с другой стороны по сравнению с изучением нескольких СУБД и их диалектов - это чепуха :)).
      Таким образом, когда вы выбираете что же использовать, перед вами стоит дилема - разработать продукт быстрей и с меньшим количеством трудозатрат, или разработать приложение, которое возможно будет работать эффективней. Я выбираю первый вариант всегда, когда это возможно. Однако когда речь идет об очень высоконагруженных приложениях, а также в вашей команде есть сильный DBA, то ORM скорей всего будет не лучшим выбором.
      • JPA2 (Java Persistent API) - это стандарт, который на данный момент (апрель 2011) входит в состав стандарта EJB3. Представляет собой набор аннотаций для маппинга сущностей на таблицы реляционной БД. Является только набором интерфейсов и аннотаций, реализаций всего этого добра довольно много: Hibernate, EclipseLink, реализации разных апп серверов. JPA имеет смысл использовать если вы хотите а) следовать стандартам в мире Java б) менять реализации JPA (например, для сравнения производительности или для написания библиотеки, которую можно будет использовать в других проектах и подставлять свои реализации). Однако часто чистого JPA не хватает, поэтому приходится использовать механизмы конкретной реализации, что уже само собой будет бить по переносимости.
      • Hibernate - самый популярный Java ORM, который может использовать как аннотации (те, что входят в JPA, и дополнительные свои), а также XML. Если вам не критичны стандарты, если вы не собираетесь менять ORM'ы как носки, то удобно использовать Hibernate как отдельный продукт, а не как реализацию JPA. Это вам даст: а) много разных фич, которые не входят в JPA б) свободу выбора то ли это будут аннотации, то ли это будет XML. Замечу, что разработчики Hibernate активно участвуют в разработке JPA, однако в сам стандарт фичи попадают намного позже, поэтому если вам хочется использовать самые прогрессивные и современные фичи ORM'a, используйте Hibernate. Также он предоставляет два вида создания запросов: Criteria API, который удобен для создания динамических запросов, и HQL - hibernate query language, который напоминает SQL.
      • JDO - изначально он разрабатывался как Java ORM standard, который может работать с любым data source (как БД, так и XML? так и что-то другое), однако особой популярности так и не приобрел. Однако он нужен, если вы собираетесь работать с Google App Engine. Чем он отличается от Hibernate: синтаксис запросов не SQL-подобный, а Java-подобный; после компиляции нужно запускать code enhancer, что добавляет еще один шаг в цикле разработки (хотя IDE имеют плагины, чтоб это делалось автоматически, ну и инструменты для сборки конечно это умеют), в то время как тот же Hibernate может работать в обеих режимах, как с enhancer'ом, так и без него. Опять же одного стандарта как правило мало, поэтому часто приходится использовать implementation-spefic механизмы; на самом деле отличий еще довольно много, для большего понимания читайте POJOs In Action.


  • Сетевые протоколы - это протоколы для общения двух или нескольких приложений по сети, включая одно- и разно-родные языки/платформы. Они делятся на две группы: двоичные (скорость) и текстовые (читабельность).
    • Google Protobuffers (Protobuf) - бинарный протокол, очень быстр. Имеет реализации под разные платформы, включая .Net, возможен RPC. Из недостатков - ограниченные возможности, к примеру, нет поддержки наследования (хотя есть обходные пути, но.. все ж не то). Из плюсов: имеет разные режимы, например, максимальная скорость, максимальное сжатие; можно писать так, чтоб в разных приложениях были разные (но при этом они должны быть совместимые) версии разметок. Для Java-Java общения разметку можно вообще не писать, причем в таком случае достигается максимальная скорость.
    • ZeroC ICE - позволяет создавать разметку (Slice) в текстовом виде, затем из этой разметки генерить код (ммм. говнокод следует заметить), имеет реализации для многих языков. На практике встречались проблемы с .Net реализацией в многопоточном режиме, когда приложение просто висло, исправили это или нет - без понятия. Инструмент достаточно мощный, это целая платформа, которая позволяет создавать разноплатформенные Grid'ы. Обертки к примитивам не поддерживает (в принципе логично, не во всех языках наверно они есть), поэтому в крайнем случае нужно будет создавать свои классы-обертки и писать на разметку. Работает медленней Protobuf, места также занимают объекты больше, правда они выпустили поддержку Protobuf протокола. Однако поддерживается наследование, правда, из недостатков - все сериализуемые сущности должны реализовывать его собственный Object. Разметка достаточно некрасивая.

  • Web
    • Servlets API - представляет собой простой фреймворк для разработки веб приложений, подходит для любых приложений, используя Serlvets API можно сделать любой сайт, однако т.к. он представляет собой довольно низкую абстракцию, писать на нем крупные сайты довольно трудоемко, многое из того, что уже реализовано в Web MVC фреймворках, нужно реализовывать самому.
    • JSF - это web mvc framework, который представляет собой компонентно-ориентированный MVC. Т.к. обычно в реализациях JSF довольно много готовых, часто используемых компонентов, то разрабатывать стандартные вещи довольно просто. Если же нужно что-то более изощренное, чем стандартные компоненты, то приходится их реализовывать самому, что не очень-то просто. JSF является хорошим решением, когда нужно написать веб приложение, которое должно индексироваться поисковиками, и при этом не хочется писать ни HTML, ни JavaScript. Многие жалуются на плохую производительность JSF фреймворков, однако вы не заметите различия если у вас не высоконагруженное приложение с точки зрения количества кликов.
    • Spring MVC, Struts - это такие фреймворки, которые предоставляют готовую инфраструктуру с точки зрения обработки запросов, однако вид все равно придется писать самому, что включает в себя как HTML, так и JS. Если у вас есть верстальщики и/или вам нужно реализовывать нестандартные и изощренные эффекты и компоненты, то писать HTML и JS вам все равно придется, поэтому Spring MVC будет подходящим решением для вас, если JSF не подходит из-за недостатков, перечисленных выше.
    • ZK, GWT, Vaadin - это такие Web MVC фреймворки, которые генерируют HTML и JS сами, при этом вы пишете что-то на Java, а они уже конвертируют это в нужную разметку. Т.к. эти фреймворки работают на AJAX, то они не годятся для случаев, когда нужно индексирование - никакие поисковики их не возьмут. Эти фреймворки подходят для внутренних или просто закрытых приложений (или их частей), где не нужно индексирование. С этими фреймворками можно сделать приятный и удобный интерфейс не написав ни строчки JavaScript'a вручную. ZK - очень быстр, но внутри страшных говнокод, дебажить и патчить такое - не благодарное дело. Vaadin наоборот создает впечатление медлительности, однако внутри просто няшка.
      Большое отличие есть между ZK и GWT/Vaadin. У первого просто есть компоненты, которые часто общаются с сервером. Вторые же генерируют JavaScript (это один из шагов после компиляции приложения, причем не самый быстрый) и логика осуществляется в основном на клиентской стороне.

  • Распределенные технологии
    • Compute Grids - это те технологии, которые используются для сложных вычислений, когда нужно распаралелливать один запрос на много узлов.
      • Apache Hadoop - из тех распределенных фреймворков, которые реализуют Map/Reduce алгоритм для обработки данных. Хадуп годится для сложной обработки огромных массивов данных. Например, Facebook использует его для парсинга логов, которых за день набирается по несколько терабайт. Выполнение любой задачи будет занимать не меньше нескольких секунд во-первых потому, что нужно время для распределения задач по узлам, во-вторых потому что все промежуточные результаты Hadoop сохраняет на жесткий диск, поэтому этот фреймворк не предназначен для ситуаций, когда ответ нужен мгновенный (такие как поиск по ключевым словам к примеру). По этим же причинам не годится для обработки в принципе маленьких задач, которые занимают секунды, ибо накладные расходы будут выше, чем трудозатраты на обработку задач. Обычно для использования Хадупа нужны гига-тера-пика-байты статических данных.


  • Интеграционные решения
    • Web Services - как правило их ниша сводится к открытым (реже - к закрытым) ресурсам, которые предоставляют платформо-независимый API. Например, у вас есть популярный сайт навроде соц. сети, к которому вы хотите сотворить API, чтоб разработчики во всем мире писали для него клиенты, плагины, чтоб кто угодно мог интегрироваться с вами. Это случай, когда стоит рассматривать веб службы - то ли SOAP, то ли REST. Есть два подхода писать SOAP WS, которые кардинально отличаются друг от друга:
      • WSDL first - это когда вы пишете WSDL в виде XML, а затем генерируете java код по нему. Этот подход трудозатратен, но вы точно контроллируете контракт (wsdl файл) и выдаете наружу красивый файл. Следовать этому подходу имеет смысл, когда вы пишете публичный сервис, который будет использоваться кем угодно в сети, потому как принесет меньше головной боли тем, кто хочет использовать вашу службу.
      • Code first - это когда вы пишете аннотированные классы, а затем генерируете WSDL по ним. В результате генерируется некрасивый, но рабочий, контракт. Этот способ, наверное, более распространен, ибо намного менее трудозатратен и в придачу работоспособен :) Поэтому для закрытых приложений, где возможно переиспользовать те же jar, или когда всем наплевать что там за контракт, они все генерируют, имеет смысл скорее использовать этот подход. Единственное - с веб службами не особо разберешься в деталях, если следовать code first. Еще одно но - генерируемый WSDL иногда бывает не переносим на другие платформы. Если .Net как правило будет работать с таким контрактом без проблем, то некоторые менее популярные платформы могуты выбрасывать ошибки типа "што за какашко, я такого не знаю", прежде чем выбирать этот подход убедитесь, что принимающая сторона точно будет понимать вас.

    • MOM (message oriented middleware) - это решения типа JMS, которые как правило используются в закрытых корпоративных приложениях. Причины почему MOM выбирают в данном случае вместо WS:
      1. Нет необходимости в чем-то слишком универсальном, как правило внутри корпорации используется какая-то одна реализация MOM и никому не нужно это API выдавать наружу, где его будет использовать широкая мультиплатформенная публика.
      2. MOM надежен, т.к. сообщение не может не дойти (разве что сама MOM упала). Кроме того многими MOM поддерживается гарантированная доставка, которая может сохранять сообщения в постоянное хранилища типа БД вместо того, чтоб держать их в памяти как это делает обычная доставка, что значит, что сообщения не погибнут даже если MOM упало.
      3. MOM поддерживает pub/sub архитектуру. То есть сообщения могут рассылаться сразу многим подписчикам вместо одного, причем отсылающий может ничего не знать о том, кто его слушает.
      4. MOM позволяет доставлять сообщения даже если в данный момент приложение с другой стороны недоступно, - сообщение доставится как только сервер поднимется (называется Durable Subscription).
      5. MOM - это асинхронная модель, что значит, что отправитель отсылает сообщение и продолжает себе работать вместо того, чтоб ждать ответ в том же потоке. Такая асинхронная природа предоставляет много гибкости. Например, был выслан запрос на данные, ответ пришел через минуту, эти данные подхватились и затем клиент еще и ожидает обновлений если такие приходят. Это может поддерживаться только с помощью асинхронной архитектуры.
      6. С помощью MOM просто отсылать бинарные данные, они ничем не отличаются от обычных. Таким образом можно даже отсылать сериализованные Java объекты и десериализовывать их на другом конце.
      7. MOM поддерживают транзакционность - то бишь если мы отсылаем два сообщения двум разным получателям и хоть одно из них не дошло (например, второй подписчик в ауте счас), то транзакцию можно откатить будто сообщения не отсылались (на самом деле здесь возможны очень много опций и поведений).

    • Apache Camel, Spring Integration - эти два фреймворка делают работу с MOM максимально приятной. Есть некие Enterprise Integration Patterns, которые описывают как можно использовать MOM, так вот эти фреймворки реализуют эти шаблоны и эту архитектуру. Они позволяют описывать маршруты, по которым должны ходить сообщения, задавать фильтры, перехватчики, трансформеры, реализовывать load balancing и failover и т.п. Однако это еще не все, они позволяют работать с разными видами транспорта, то бишь не только Messaging как таковой, но и.. например файловая система. Допустим вы получаете сообщение по WS, затем его нужно переслать другой системе по ActiveMQ, затем дождаться ответа и сохранить результат в файл; а если ответ не приходит в течение некоторого времени, то отсылать мейл администратору с ошибкой - весь этот маршрут можно задать с помощью данных фреймворков, причем все эти endpoint'ы будут работать с одной абстракцией - Message. В противном же случае вам бы пришлось а) работать напрямую с JAX-WS, JMS, JavaMail, IO и строить маршрут с помощью разных if-ов в Java коде. Пример XML based Camel, Пример Spring Integration.


Список будет постоянно пополняться.
Если вы хотите услышать про какую-то определенную технологию/фреймворк/библиотеку, пишите в личку запросы. Предупреждаю, что не обязательно это выльется в какой-то результат, ибо описываю здесь только то, о чем знаю.
Изменен:11 июл 2018 05:09
 
 
Сообщения:88
хм...работаю сейчас с vaadin,заявлени о его няшности мне кажется немножко приувеличенным
 
 
Сообщения:2
time2die:
хм...работаю сейчас с vaadin,заявлени о его няшности мне кажется немножко приувеличенным


У нас как раз сейчас стоит задача выбрать фреймворк для RIA.
Решаем Vaadin или опуститься ниже на GWT.
Vaadin подкупает скоростью разработки и желанием забить на реализацию взаимодействия между клиентом и сервером. Помимо этого есть необходимость работать с БД через JDBC, но как говорит документация GWT - google app engine имеет с этим проблемы.
 
 
Сообщения:10007
time2die, ты говоришь про внешний вид или состояние исходников самого Vaadin? Я про исходники говорил.
vanessky, лучше всего сделать несколько POC с каждой из технологий: ZK (обязательно ZK6 с его MVVM, мне он намного больше нравится всяких MVP), Vaadin, GWT и более или менее сложными компонентами (дерево, по нажатию на которое появляется таблица, и если кликнуть на таблицу, то что-то еще вылазит), иначе будет пальцем в небо. Лучше потратить на это две человеконедели, чем потом жалеть о сделанном выборе.
Внешне самый шустрый все-таки ZK, но если придется его дебажить, то это надолго :)
 
 
Сообщения:2
Староверъ:
time2die, ты говоришь про внешний вид или состояние исходников самого Vaadin? Я про исходники говорил.
vanessky, лучше всего сделать несколько POC с каждой из технологий: ZK (обязательно ZK6 с его MVVM, мне он намного больше нравится всяких MVP), Vaadin, GWT и более или менее сложными компонентами (дерево, по нажатию на которое появляется таблица, и если кликнуть на таблицу, то что-то еще вылазит), иначе будет пальцем в небо. Лучше потратить на это две человеконедели, чем потом жалеть о сделанном выборе.
Внешне самый шустрый все-таки ZK, но если придется его дебажить, то это надолго :)


А можно поподробнее про сложности отладки ZK? А то немного посмотрев его приходиться слюни со стола подбирать :)
 
 
Сообщения:10007
Ну по нему достаточно мало документации, поэтому если возникают трудности и на форуме с ними не могут помочь, значит приходится дебажить и проверять почему ж оно все-таки не работает и как надо. И вот тогда и обнаруживаются методы с десятками условий и по сотне строк..
 
 
Сообщения:2441
Я бы разделил тройку ZK, GWT и Vaadin. Сейчас про них всё верно написано, но между ними есть глубокие архитектурные различия. Поэтому эту троицу позволяющую писать AJAX проиложения без применения javascript, я бы разделил еще на 2 подгруппы:
1. ZK, Vaadin - нацелены на обработку событий на сервере, в них можно конечно как-то строить обработку событий на клиенте, но это не вписывается в их идеалогию и часто лишь написание Javascript собственными ручками является единственным способом обработки событий на клиентской стороне. В ориентации на обработку событий на сервере есть как плюсы так и минусы, плюсом является высочайшая скорость разработки связанная с тем что браузер вообще исключается, а следовательно не нужно программировать коммуникацию клиента и сервера. Минусом является увеличением нагрузки на серверную часть, следовательно область применение ZK и Vaadin это внутренние корпаративные приложения, где пользователь не просто случайно на сайт через поисковик забрел, а выполняет полезную для предприятия функцию и за лишнюю нагрузку в приложениях чья бизнесс модель не является с миру по нитке рубаха будет эти два фреймворка вполне подходят. Ближайший конкурент это JSF, но в нем отсутсвует полноценная абстракция от Ajax.
2. В GWT вся обработка событий происходит на клиенте. В этом то же есть как плюсы так и минусы. Плюс в том, что не всякое событие требует обработки на сервере следовательно значительно экономится траффик и нагрузка перекладывается на клиента, а сервер можно вообще делать stateless, минус в более низкой скорости разработки так как API между браузером и сервером нужно проектировать явно. Область применения GWT шире чем ZK и Vaadin, его также можно применять для корпаративных приложений в случаях когда предъявляются очень высокие требования к скорости или сложности интерфейса и можно пожертвовать увеличением времени на разработку. Но так же GWT можно применять и для разработки публичных приложений с высокой нагрузкой, для которых достаточно индексирования нескольких главных страниц. В GWT вся нагрузка с сервера перекладывается на клиента, в то время как ни ZK ни Vaadin в публичных сайтах использовать не рекомендуется из-за кеширования DOM дерева клиента на сервере. Конкурентов у GWT в настоящее время нет и я подрзреваю что не только в java, их нет в любом другом языке.
 
 
Сообщения:2441
Да кстате в догонку. MVP сильно нужен в интерпрайз, где на формочках по 10-30-50 компонентов и ГУИ сложен до такой степени что сама логика ГУИ выделяется в отдельный самостоятельный архитектурный слой реализуемый в презентерах. Если у Вас другой случай и логика ГУИ либо вообще отсутсвует, либо очень простая то да MVP это явный оверхед. Но вот конкретно в случае сложной логики ГУИ возможность тотального тестирования пользовательского интерфейса полноценными модульными тестами без применения Selenium и иже с ним, явно на стороне MVP и невилирует некоторую многословность присущую этому шаблону. Что же касается MVVM то да этот паттерн радикально сокращает код, действительно такой краткости как в ZK6 недобиться нигде, но также нельзя не упоминуть что MVVM увеличивет количество точек неконтролируемых компилятором и не покрываемых обычными юнит тестами. Так что выбор нужно делать по ситуации, возможно скажем в административной панели лучше MVVM, а в функционале для пользователя который явно будет посложнее лучше MVP.
Изменен:17 фев 2012 23:03
 
 
Сообщения:88
Староверъ:
time2die, ты говоришь про внешний вид или состояние исходников самого Vaadin? Я про исходники говорил.

я тоже говорил про исходники, возможно я не достаточно глубоко копался в коде, но в душу запали ОГРОМНЫЕ классы по тысяче строк + функция копирования коллекции реализованная руками и малая гибкость некоторых компонентов. С другими web gui фреймворками не работал, возможно потому он мне и не сильно понравился

чтобы не быть голословным

private LinkedList<UserChangeListener> userChangeListeners = null;
...
  public void setUser(Object user) {
        final Object prevUser = this.user;
        if (user == prevUser || (user != null && user.equals(prevUser))) {
            return;
        }

        this.user = user;
        if (userChangeListeners != null) {
            final Object[] listeners = userChangeListeners.toArray();
            final UserChangeEvent event = new UserChangeEvent(this, user,
                    prevUser);
            for (int i = 0; i < listeners.length; i++) {
                ((UserChangeListener) listeners[i])
                        .applicationUserChanged(event);
            }
        }
    }

Apllication class
 
 
Сообщения:2441
Исходники не всегда пропорционально коррелируют с качеством фреймворка. Что там далеко ходить загляните в исходники самого Java, в них очень много вопросов для обычного программиста занимающегося прикладной разработкой, но что-то мне подсказывает что скажем Джошуа Блох не быдлокодер, а разработчик пытавшийся реализовать функции которые будут использованы сотнями тысяч разработчиков максимально эффективно, в следствии чего их реализация не всегда всем понятна. От библиотечного кода никогда не пахнет фиалками в отличии от прикладного кода, который рассчитан на применение в какой-то конкретной предметной области. Да и реализация имеет второстепенное значение по сравнению с абстракцией которою даёт фреймворк, если Вы загляните в исходнике ZK то совсем решите повесится, а тем не менее этот фреймворк предоставляет очень хорошую абстракцию от javascript, AJAX, COMET чего не могут предоставить другие фреймворки (за исключением Vaadin, GWT) которые до блеска вылезанные но абсолютно бесполезные в деле абстракции от javascript.
 
 
Сообщения:88
уточню на свою точку зрения, лично мне vaadin кажется местами не гибким и не продуманным, я адекватно осознаю что это может быть как следствием малого опыта вообще, так и в работе с фреймворками подобного толка.

опять же, что бы не ходить далеко - vaadin не позволяет в разных потоках проводить манипуляцию с элементами(менять данные, удалаять\добавлять), стандартного функционала подобного SwingUtilities.invokeLater в официальной документации найдено не было
 
 
Сообщения:2441
time2die:

опять же, что бы не ходить далеко - vaadin не позволяет в разных потоках проводить манипуляцию с элементами(менять данные, удалаять\добавлять), стандартного функционала подобного SwingUtilities.invokeLater в официальной документации найдено не было

А вы понимаете разницу между WEB и Desktop приложением? У WEB есть только один шанс изменить что-то в ГУИ, это время обработки HTTP запроса пришедшего от браузера, запрос обработан всё поезд ушел. За vaadin говорить не буду так как с ним не работал, но в ZK аналог SwingUtilities.invokeLater есть это EventQueue или ServerPush, но так как чудес не бывает за него приходиться расплачиваться либо открытым comet соединением либо периодическим опросом сервера, то есть когда Http запрос от клиента уже обработан, дорисовать что-то в браузере по инициативе сервера можно только расплатившись ресурсами, это собственно ограничение WEB приложений вообще, никак не связанное с каким нибудь отдельно взятым фреймворком.
 
 
Сообщения:88
Vermut:
time2die:

опять же, что бы не ходить далеко - vaadin не позволяет в разных потоках проводить манипуляцию с элементами(менять данные, удалаять\добавлять), стандартного функционала подобного SwingUtilities.invokeLater в официальной документации найдено не было

А вы понимаете разницу между WEB и Desktop приложением? У WEB есть только один шанс изменить что-то в ГУИ, это время обработки HTTP запроса пришедшего от браузера, запрос обработан всё поезд ушел. За vaadin говорить не буду так как с ним не работал, но в ZK аналог SwingUtilities.invokeLater есть это EventQueue или ServerPush, но так как чудес не бывает за него приходиться расплачиваться либо открытым comet соединением либо периодическим опросом сервера, то есть когда Http запрос от клиента уже обработан, дорисовать что-то в браузере по инициативе сервера можно только расплатившись ресурсами, это собственно ограничение WEB приложений вообще, никак не связанное с каким нибудь отдельно взятым фреймворком.

чуть-чуть понимаю, в vaadin постоянно идут ajax запросы так как на стороне сервера реализована вся логика, а на стороне клиента только отображение. Я говорил о том,что если у вас есть потом, который например следит за внешним объектом(базой данных, устройством) и изменяет поле статистики, то это выливается в ошибки(в тестовом окружении я смог нарепродюсить порядка 5 разных ошибок) исправить которые используя продуманность фреймворка возможности нет(лично мы с коллегами не нашли) и прийдется использовать костыли.

Я не хочу сказать что Vaadin плохой фреймворк, он мне очень нравится и скоростью разработки и отсутствием необходимости лезть в javascript просто в некоторых местах он не гибок

не холивара ради а справедливости для
 
 
Сообщения:102
А по Spring Framework / EJB почему ничего не написали?
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет