Должен ли я определять источники данных в приложении или на сервере приложений?

Я разработал приложения (работающие на сервере Jboss) с двумя разными командами. У одной команды была конфигурация источника данных внутри файла WAR приложения, а другая - внутри сервера приложений standalone.xml. И я не уверен, какой подход лучше.

Итак, вот некоторые преимущества, которые я нашел в определении источника данных внутри сервера standalone.xml.

  • Определение источника данных в сервере standalone.xml более безопасно, чем в военном файле. Если учетные данные подключения к базе данных хранятся на сервере standalone.xml, который почти никогда не изменяется, он безопаснее, чем наличие пароля внутри военного файла, который часто переносится с машин разработчика на сервер и конфигурация базы данных распространяется всеми разработчиками компьютеры.
  • Имея источник данных в файле standalone.xml, мы можем сделать военный файл меньше, поскольку драйвер JDBC можно установить как модуль и удалить из военного файла. Кроме того, загрузка JDBC в качестве модуля более эффективна, чем из пути к классам.
  • Мы можем поместить источник данных в файл standalone.xml, если мы не хотим, чтобы команда разработчиков приложений знала настройки подключения к базе данных.

Имея конфигурацию источников данных в файле WAR приложения, я вижу следующие преимущества:

  • Команда разработчиков не имеет права изменять файлы конфигурации Jboss в среде, где работает Jboss. Таким образом, соединение DB может быть определено в приложении.
  • Это полезно в состоянии разработки, когда разработчикам часто приходится переключаться между различными подключениями к базе данных. Например, разработчик может указать соединение при создании WAR файла.

Поэтому я хотел бы знать, есть ли другие преимущества в обоих подходах. И на ваш взгляд, какой подход лучше?

Ответы

Ответ 1

В дополнение к пунктам, отмеченным в вопросе, еще одно преимущество наличия источников данных вне приложения заключается в том, что он позволяет использовать один и тот же файл войны в разных регионах. Это позволит команде иметь разные базы данных для разных сред, таких как Test, Perf и Prod при использовании одного и того же файла войны.

Вы можете сделать развертывание один раз, а затем файл войны, который был проверен вашей командой QA, можно продвинуть в область производства. Это позволит убедиться, что непроверенный код переходит в более высокие регионы, избегая при этом необходимости вилки и кодов SCM.

Ответ 2

Я предпочитаю, чтобы источник данных был открыт сервером приложений с оговоркой. Вам нужна ваша команда разработчиков, чтобы хотя бы знать свой путь с вашим сервером приложений или иметь хотя бы доступ к консоли jboss, чтобы просмотреть конфигурацию или изменить ее. Причина в том, что, например, им необходимо отслеживать использование соединения пула соединений с источником данных. Поскольку вы говорите о jboss, я не знаю, поддерживает ли "живой" bean для источника данных с jboss AS выдает ту же информацию изначально, например, oracle ucp (ucp.getStatistics - godSend для более чем одной причины..).

Учтите, что EVEN, если вы интернализируете источник данных в xml, используя концепцию профилей, вы можете сделать какое-то поле xml "заполненным" определенным значением в том или ином файле свойств на основе профиля, в который приложение загружается..

например, с помощью spring вы можете сделать

    <beans profile="local">
    <bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
        <property name="URL" value="jdbc:oracle:thin:@db00-ccea.labucs.int:1521:CCEA"/>
        <property name="user" value="myuser_DCI"/>
        <property name="password" value="mypassword_DCI"/>
        <property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
        <property name="connectionPoolName" value="${name.connection.pool}"/>
        <property name="minPoolSize" value="5"/>
        <property name="maxPoolSize" value="1000"/>
        <property name="maxIdleTime" value="3000"/>
        <property name="maxStatements" value="3000"/>
        <property name="validateConnectionOnBorrow" value="true" />
        <property name="inactiveConnectionTimeout" value="3000" />
        <property name="connectionWaitTimeout" value="3000"/>
        <property name="abandonedConnectionTimeout" value="3000"/>
        <qualifier value ="dataSourceDCI" />
    </bean>
    <orcl:pooling-datasource id="dataAltSource"
        url="jdbc:oracle:thin:@db00-ccea.labucs.int:1521:CCEA" username="some_OWN" password="some_OWN"/>
        <util:properties id="flyway.prop" location="classpath:config_local.properties"/>
</beans>

Значение в локальном профиле загружает свойства из файла config_loca.properties внутри пути к классам

а также

    <beans profile="qa">
    <bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
        <property name="URL" value="jdbc:oracle:thin:@db00-ccea.labucs.int:1521:CCEA"/>
        <property name="user" value="myuserQA_DCI"/>
        <property name="password" value="myuserQA_DCI"/>
        <property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
        <property name="connectionPoolName" value="${name.connection.pool}"/>
        <property name="minPoolSize" value="5"/>
        <property name="maxPoolSize" value="1000"/>
        <property name="maxIdleTime" value="3000"/>
        <property name="maxStatements" value="3000"/>
        <property name="validateConnectionOnBorrow" value="true" />
        <property name="inactiveConnectionTimeout" value="3000" />
        <property name="connectionWaitTimeout" value="3000"/>
        <property name="abandonedConnectionTimeout" value="3000"/>
        <qualifier value ="dataSourceDCI" />
    </bean>
    <bean id="dataAltSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
        <property name="URL" value="jdbc:oracle:thin:@db00-ccea.labucs.int:1521:CCEA"/>
        <property name="user" value="myuserQA_OWN"/>
        <property name="password" value="myuserQA_OWN"/>
        <property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
        <property name="connectionPoolName" value="${name.connection.pool}"/>
        <property name="minPoolSize" value="5"/>
        <property name="maxPoolSize" value="1000"/>
        <property name="maxIdleTime" value="3000"/>
        <property name="maxStatements" value="3000"/>
        <property name="validateConnectionOnBorrow" value="true" />
        <property name="inactiveConnectionTimeout" value="3000" />
        <property name="connectionWaitTimeout" value="3000"/>
        <property name="abandonedConnectionTimeout" value="3000"/>
    </bean>     
    <util:properties id="flyway.prop" location="file:///${prefix.iam.dir}/${filecert.iam.path}/external.properties"/>
</beans>

таким образом, в вашей среде QA или в другой среде, отличной от dev, вы вместо этого ссылаетесь на внешний XML файл, а не на тот, который интегрирован в войну. Вы даже можете указать имя пользователя и пароль, которые будут "заполнены" через внутренний//файл внешних свойств, чтобы повысить безопасность, если вы заинтересованы.

Ответ 3

Чтобы правильно проверить работу вашего приложения, вы должны попробовать на промежуточном сервере, прежде чем отправлять его на производство.

В этом сценарии, файл войны, который вы устанавливаете в производство, должен быть тем же, который вы тестировали, поэтому вам не нужно ничего менять для того, чтобы приложение было работать в другой среде с разными подключениями к базе данных.

Итак, конфигурация базы данных не должна быть в военном файле, а на сервере приложений. Кроме того, вы упрощаете системный администратор, потому что им не нужно манипулировать (распаковывать и изменять) вашу войну, чтобы установить ее на сервере.

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

Ответ 4

Для меня преимуществом номер один от наличия всей конфигурации источника данных из военного файла является простота развертывания.

Если я правильно прочитал ваш вопрос, вы не можете развертывать ту же самую сборку в нескольких средах, если вы включаете какую-либо конфигурацию в сборку. Прямым следствием является то, что вы никогда не сможете развернуть DEV build до QA и, что более важно, вы не можете развернуть свою QA-сборку в PROD или UAT. Это может привести к головной боли, если ваш процесс проверен.

Если я неправильно понял ваш вопрос, пожалуйста, дайте мне знать, иначе я надеюсь, что это поможет.