Возможна ли постепенная миграция для Vaadin JavaEE на Vaadin Spring? - PullRequest
0 голосов
/ 16 февраля 2019

У нас есть существующее веб-приложение Vaadin 8 JavaEE, которое было адаптировано и сильно модифицировано из демоверсии Tickets Dashboard.Мы находимся в процессе планирования графика перехода приложения на Spring (без загрузки) и принятия модели MVC для следующей версии.Однако после прочтения документации Vaadin Spring и сравнения исходных кодов между текущим приложением, образцом приложения для хлебопекарен (Spring, с Framework 8) и более старым проектом, использующим Hibernate 4 и Spring 4, у нас все еще оставалось несколько ключевых вопросов.Требуется помочь улучшить наш подход к миграции:

  1. Возможна ли постепенная миграция, когда некоторые функции переносятся в Spring сначала, а затем другие в последующих небольших выпусках?Если да, то какие классы я должен начать модифицировать / адаптировать (кроме тех, которые указаны ниже) к Spring, прежде чем переходить к более мелким версиям?

  2. Мы установили, что 75% нашего приложенияиспользуя сложные собственные запросы выбора, с 25% на операции CRUD.Мы все еще придерживаемся Hibernate, так как большинство разработчиков знакомо с ним.Лучше придерживаться универсального подхода DAO (инкапсулируя реализацию, например, https://www.baeldung.com/simplifying-the-data-access-layer-with-spring-and-java-generics) или просто используя интерфейсы JPARepository, как видно в приложении Baker?

  3. Мыразвертывание приложения в облаке Azure с TomEE Plume (эквивалент Tomcat 8.5) в качестве начального развертывания. Какие специальные параметры следует включить для обеспечения этого развертывания?

Мы задали вопросэтот вопрос о постепенной миграции ранее на форуме Vaadin, но без каких-либо ответов: https://vaadin.com/forum/thread/17468362/17468363

Нашими ближайшими целями после запланированного процесса миграции будет:

  1. Сделать его модульными упростить включение последующих функций, таких как динамическая маршрутизация данных, автоматический выключатель / перенаправление, уведомление по электронной почте, интернационализация, сохранение количества управляемых экземпляров на уровне 5-10 на уровне производства и т. д.

  2. Сохранение открытой возможности для модернизации без необходимости переписывать всенапример, в течение следующих нескольких лет (от Java 8 до Java 11, от Framework 8 до Vaadin 12).

Как уже было сказано выше, это для работы в облаке Azure с базой данных MSSQL и контейнером TomEE Plume.

Мы сделали несколько предварительных изменений кода, включая:

  1. Изменение основного файла pom.xml и включение лучшего профилирования maven (с использованием https://www.mkyong.com/maven/maven-profiles-example/ в качестве справочного материала)

  2. Перенос настроек гибернации и пружинык файлам application.properties

  3. Добавлен application-context.xml и разделить его снова на application-context-dao.xml и application-context-service.xml, чтобы сделать его управляемым.

Web.xml

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:applicationContext.xml</param-value>
</context-param>

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
    <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>

<servlet>
    <servlet-name>SycardaDashboard2</servlet-name>
    <servlet-class>com.example.dashboard.DashboardServlet</servlet-class>
    <init-param>
        <param-name>UI</param-name>
        <param-value>com.example.dashboard.DashboardUI</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>SycardaDashboard2</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

application-context.xml

<beans>
    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
            <list>
                <value>classpath*:application-development.properties</value>
                <value>classpath*:application-production.properties</value>
            </list>
        </property>

    </bean>
<import resource="classpath*:applicationContext-dao.xml" />
<import resource="classpath*:applicationContext-service.xml" />

<context:component-scan base-package="com.example.dashboard">
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
</beans>

application-dao-context.xml

<!-- Activates scanning of @Autowired -->
<context:annotation-config/>

<!-- Activates scanning of @Repository -->
<context:component-scan base-package="com.igi.sycarda.dashboard.dao"/>

<bean class="org.springframework.orm.hibernate4.HibernateExceptionTranslator"/>
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

<bean id="sessionFactory" class="org.springframework.orm.hibernate5.LocalSessionFactoryBean" destroy-method="destroy">
    <property name="dataSource" ref="dataSource" />
    <property name="packagesToScan">
        <list>
            <value>com.example.dashboard.entities</value>
        </list>
    </property>
    <property name="hibernateProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.query.substitutions">true 'Y', false 'N'</prop>
            <prop key="hibernate.cache.use_second_level_cache">true</prop>
            <prop key="hibernate.cache.use_query_cache">true</prop>
            <prop key="hibernate.cache.region.factory_class">org.hibernate.cache.ehcache.EhCacheRegionFactory</prop>
            <prop key="current_session_context_class">thread</prop>

            <prop key="show_sql">${hibernate.show.sql}</prop>
            <prop key="format_sql">${hibernate.format.sql}</prop>
            <prop key="use_sql_comments">${hibernate.use.sql.comments}</prop>
        </props>
    </property>
</bean>

<!-- Transaction manager for a single Hibernate SessionFactory (alternative to JTA) -->
<bean id="transactionManager" class="org.springframework.orm.hibernate5.HibernateTransactionManager">
    <property name="sessionFactory" ref="sessionFactory"/>
</bean>

Для начала, после первой недели миграции мы ожидаем, что приложение все еще будет на 90% JavaEE, и одна или две функции будут в Spring.После каждой недели обновлений количество существующих функций будет переходить на использование Spring до тех пор, пока оно не будет полностью включено.

1 Ответ

0 голосов
/ 17 февраля 2019

Такая миграция возможна.У вас есть несколько вопросов в этом вопросе. Я отвечу только на два из них.

  1. Возможна ли постепенная миграция? Да, это возможно, и вы можете либо центрировать его сначала снизуслои - ваши DAO и репозитории в случае сложного монолита.Или вы можете попробовать разделить ваше приложение на небольшие логические блоки и попытаться перенести эти блоки.Примером такой нарезки может быть, если у нас на сайте электронной коммерции есть услуга, рассчитывающая цену товара.Это четко определенный сервис, который можно легко изолировать.Такой подход также даст вам более полное представление о том, как вы хотели бы модульности вашего приложения.Иногда, хотя такой подход может быть слишком сложным для больших монолитов, где код просто сфагетти.
  2. Использование данных Spring и миграция существующих Daos .Не обязательно, чтобы вы использовали данные весны.Наличие DAOS или репозиториев, написанных вручную, прекрасно.На мой взгляд, не нужно прилагать дополнительных усилий или выполнять дополнительную работу с такой миграцией.

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

...