Если так с UI, то это интересно. Предположу, что и в слое работы с хранением объектов у вас тоже обертка вокруг репозиториев-сервисов, которые принято делать в традиционной Spring-архитектруе приложения. Тогда вопрос: Как удается достичь производительности в слое хранения, если даже при обертывании ORM каким-нибудь "Spring Data" возрастает сложность предсказать — как оно там будет работать на уровне SQL-запросов, требуется тонкая настройка ORM?
Vaadin 8 будет до 2022 года поддерживаться, корпортаивные системы делаются долго.
Не получится ли так, что как только кто-то сделает систему на Cuba 7 так пора будет ее переделывать на Cuba 8, который на каком-нибудь Vaadin 1X?
Но, в JS это нормально, потому что понятия класса, функции, методов класса размыты. Слабая типизация во всем.
до "ECMAScript 2015" в нем нет классов, там наследование основано на прототипах.
функция "Person" является объектом-конструктором, а
new Person("Igor", 26);
создаст объект-экземпляр.
Динамическая природа JS проявится в том, что можно на-ходу добавлять поля/методы к прототипу объекта-конструкора и они становтся доступы у всех объектов-экземпляров.
К "классовом" языке свойства и методы класса динамически менять не получится.
Все это хорошо пока не дойдешь до динамических запросов с несколькими параметрами, на что есть два решения: QueryDSL и JPA Specifications.
QueryDSL, как я понял, малопопулярен. Но во обоих случаях придется писать довольно много кода, что сравнимо с Criteria API. Тогда зачем еще один уровень абстракции, если можно это сделать со старым, добрым Criteria API? Что я и стал пока делать.
У корпораций нет проблем с деплоем (Бобук). Зато у простых смертных с этим Python, Ruby, PHP полно проблем с деплоем. И Docker-образ надо правильно "сварить" для этих дел.
Потом все это еще обновлять с плясками.
После всего этого жутко нравиться Java, где есть только одна зависимость — JVM, и это прекрасно. Понятно, что системы часто еще требуют и БД, которые часто не-Java, но все же.
Почему бы не взять Vaadin или ZK Framework и не вернуть разработку фронтэнда на бэк?
Судя по тому, что они использовали Dojo Toolkit, то приложения были для предприятий и указанные выше фреймворки с довольно богатым набором компонентов самое оно то.
Почему void? Понятно, что он пишет ответ в объект resp по старинке, это как-то неявно.
Еще, почему @EJB, а не @ Inject ?
Про Spring, API JAX-RS из JavaEE, по-моему получше выглядит, чем Spring Web c @RestController. По-моему стало бы лучше, если Spring по аннтациям приближался к спецификациям JavaEE. Hibernate хороший пример, он соответствует JPA.
… Если дело так пойдет дальше, Браун нас не только догонит, но и первым окажется на Луне».
«Ну, это исключено» – Королев уставился взглядом в возвышавшийся перед ним Протон. – «Он решил создать супердвигатель на 700-800 тонн тяги на криогенных компонентах топлива. Пусть поковыряется, пока не упрется в стену. Мы уже это проходили».
(Н.В. Лебедев. Из воспоминаний ракетчикаю)
Поддерживаю. Есть ряд важных проблем в 8-ой версии, которые не решены и не понятно уже будет ли решение. Например, важнейший компонент Grid нельзя прокрутить до нужной строки, если данные подгружаются "лениво". После редактирования записи пользователь не видит, какая строка только что им редактировалась. https://github.com/vaadin/framework/issues/9266
Разработчик Vaadin пометил этот запрос как "Расширение"(!) и прогресса не видно.
Думаю проблема в том, что основные контрибьюторы проекта штатные сотрудники Vaadin Inc., которые очень лихо бегут вперед и программисты из сообщества не успевают разобраться и починить то, что хотят.
Не подскажете в чем причина такой ошибки:
Caused by: java.lang.IllegalArgumentException: Failed to create query method public abstract java.lang.Iterable org.springframework.data.querydsl.QueryDslPredicateExecutor.findAll(com.querydsl.core.types.OrderSpecifier[])! No property findAll found for type MyClassName!
Понятие "сервер приложений" довольно размытое, можно тогда полноценными считать те, что реализует JEE спецификации. А можно их все называть серверная среда исполнения — Runtime.
Я правильно понимаю, что это для микросервисной архитектуры? То есть пока у нас была БД, как поставщик данных, то она редко была нетерпимо медленной, если же была, то выставлялся кэш в памяти. Теперь данные идут от микросервисов, которые могут быть довольно тормознутыми. Чтоб не городить потоки, делают более простой способ организации параллельной работы — асинхронный, он же реактивный.
Если так с UI, то это интересно. Предположу, что и в слое работы с хранением объектов у вас тоже обертка вокруг репозиториев-сервисов, которые принято делать в традиционной Spring-архитектруе приложения. Тогда вопрос: Как удается достичь производительности в слое хранения, если даже при обертывании ORM каким-нибудь "Spring Data" возрастает сложность предсказать — как оно там будет работать на уровне SQL-запросов, требуется тонкая настройка ORM?
Vaadin 8 будет до 2022 года поддерживаться, корпортаивные системы делаются долго.
Не получится ли так, что как только кто-то сделает систему на Cuba 7 так пора будет ее переделывать на Cuba 8, который на каком-нибудь Vaadin 1X?
до "ECMAScript 2015" в нем нет классов, там наследование основано на прототипах.
функция "Person" является объектом-конструктором, а
создаст объект-экземпляр.
Динамическая природа JS проявится в том, что можно на-ходу добавлять поля/методы к прототипу объекта-конструкора и они становтся доступы у всех объектов-экземпляров.
К "классовом" языке свойства и методы класса динамически менять не получится.
Спасибо за Jinq, вижу стоит попробовать.
Все это хорошо пока не дойдешь до динамических запросов с несколькими параметрами, на что есть два решения: QueryDSL и JPA Specifications.
QueryDSL, как я понял, малопопулярен. Но во обоих случаях придется писать довольно много кода, что сравнимо с Criteria API. Тогда зачем еще один уровень абстракции, если можно это сделать со старым, добрым Criteria API? Что я и стал пока делать.
Может скажет, что "JPA Specifications" все-таки правильный путь?
Статья Using Spring Data JPA Specification как-то малоубедительна.
Только "поезд ZFS ушел" кажись. Популярные дистрибутивы Linux легко ставятся на BtrFS, который и задумывался, как замена ZFS.
У корпораций нет проблем с деплоем (Бобук). Зато у простых смертных с этим Python, Ruby, PHP полно проблем с деплоем. И Docker-образ надо правильно "сварить" для этих дел.
Потом все это еще обновлять с плясками.
После всего этого жутко нравиться Java, где есть только одна зависимость — JVM, и это прекрасно. Понятно, что системы часто еще требуют и БД, которые часто не-Java, но все же.
Почему бы не взять Vaadin или ZK Framework и не вернуть разработку фронтэнда на бэк?
Судя по тому, что они использовали Dojo Toolkit, то приложения были для предприятий и указанные выше фреймворки с довольно богатым набором компонентов самое оно то.
Зато интересно, как оно там в JavaEE делается. Вот, например, можно
без xml-а объявить сервлет и его путь:
Но дальше как-то неуклюже:
Почему void? Понятно, что он пишет ответ в объект resp по старинке, это как-то неявно.
Еще, почему @EJB, а не @ Inject ?
Про Spring, API JAX-RS из JavaEE, по-моему получше выглядит, чем Spring Web c @RestController. По-моему стало бы лучше, если Spring по аннтациям приближался к спецификациям JavaEE. Hibernate хороший пример, он соответствует JPA.
$2,000 за электричесво — считать нужно не киловатты потраченные машиной, а закачанные из розетки.
… Если дело так пойдет дальше, Браун нас не только догонит, но и первым окажется на Луне».
«Ну, это исключено» – Королев уставился взглядом в возвышавшийся перед ним Протон. – «Он решил создать супердвигатель на 700-800 тонн тяги на криогенных компонентах топлива. Пусть поковыряется, пока не упрется в стену. Мы уже это проходили».
(Н.В. Лебедев. Из воспоминаний ракетчикаю)
Поддерживаю. Есть ряд важных проблем в 8-ой версии, которые не решены и не понятно уже будет ли решение. Например, важнейший компонент Grid нельзя прокрутить до нужной строки, если данные подгружаются "лениво". После редактирования записи пользователь не видит, какая строка только что им редактировалась.
https://github.com/vaadin/framework/issues/9266
Разработчик Vaadin пометил этот запрос как "Расширение"(!) и прогресса не видно.
Думаю проблема в том, что основные контрибьюторы проекта штатные сотрудники Vaadin Inc., которые очень лихо бегут вперед и программисты из сообщества не успевают разобраться и починить то, что хотят.
Еще используется spring-data envers и в конфигурации прописано:
Не подскажете в чем причина такой ошибки:
Caused by: java.lang.IllegalArgumentException: Failed to create query method public abstract java.lang.Iterable org.springframework.data.querydsl.QueryDslPredicateExecutor.findAll(com.querydsl.core.types.OrderSpecifier[])! No property findAll found for type MyClassName!
Минусуя аргументируйте, пожалуйста.
Понятие "сервер приложений" довольно размытое, можно тогда полноценными считать те, что реализует JEE спецификации. А можно их все называть серверная среда исполнения — Runtime.
Ещеьважное свойство — встраиваемость, чтоб сделать запускаемый "толстый" jar.
Я правильно понимаю, что это для микросервисной архитектуры? То есть пока у нас была БД, как поставщик данных, то она редко была нетерпимо медленной, если же была, то выставлялся кэш в памяти. Теперь данные идут от микросервисов, которые могут быть довольно тормознутыми. Чтоб не городить потоки, делают более простой способ организации параллельной работы — асинхронный, он же реактивный.
1) можно сделать перенаправление портов с iptables 80->8080 443->8443.
2) можно запустить Apache Web-server(или что-то другое) как прокси для tomcat