Сменный слой данных с использованием Spring Ioc - PullRequest
2 голосов
/ 16 июля 2010

У меня есть DAO для каждой таблицы, которые все реализуют интерфейс.

Теперь я хочу иметь возможность (потенциально) поменять местами реализации уровня базы данных.

Так что моя стратегия - создать DaoFactory, и этот DaoFactory будет специфичен для конкретной реализации моих DAO.

Так что у меня будут DAO для спящего режима. Затем DaoHibernateFactory, который будет выглядеть так:

public class DaoHibernateFactory implements DaoFactory
{


     public UserDao GetUserDao() {

          return new UserHibernateDao();
     }


}

Затем во всех моих классах менеджера / обслуживания я буду использовать любой тип Dao___Factory, подключенный через spring ioc.

Имеет ли это смысл? Предложения?

Ответы [ 3 ]

5 голосов
/ 16 июля 2010

Я бы хотел иметь отдельные файлы конфигурации для каждой реализации, а не использовать фабрики. Таким образом, Spring может ввести ваши DAO для вас, и вам не нужно звонить или поддерживать дополнительный заводской класс.

Например:

зимуют-data.xml:

<bean id="userDAO" class="com.foo.dao.hibernate.HibernateUserDao">
    ...
</bean>

Ibatis-data.xml:

<bean id="userDAO" class="com.foo.dao.ibatis.IBatisUserDao">
    ...
</bean>

и т.д.

Затем вы можете поменять реализацию, изменив, какой файл -data включен в ваш web.xml.

2 голосов
/ 16 июля 2010

Поскольку вы используете внедрение зависимостей, вы должны попытаться использовать проводку, поставляемую «из коробки» из рассматриваемой структуры DI, а не писать собственные фабрики.

Текущую проблему можно решить с помощью SpringPropertyPlaceHolder и простого соглашения об именах DAO в файле конфигурации Spring.

Шаги: 1. Сначала используйте соглашение об именах, чтобы назвать идентификаторы ваших отдельных DAO и сконфигурировать их в весеннем файле. Пример:

<bean id='hibernateUserDao' class='UserHibernateDao'/>
<bean id='ibatisUserDao' class='UserIbatisDao'/>

Здесь мы говорим, что все Даос Hibernate начинаются с hibernate, а все Даос ibatis начинаются с ibatis и т. Д.

2.Следующая настройка потребителя Daos. Убедитесь, что проводка динамическая в зависимости от свойств.

<bean id='daoconsumer' class='some.consumer.class'>
  <property name='dao' ref='${daoImpl}UserDao'/>
</bean>

3. После этого настройте заполнитель Spring Property в файле Spring.

<bean id="propertyConfigurator" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location">
        <value>classpath:/path/to/app.properties</value>
    </property>
</bean>

4. Наконец, вы пишете app.properties одной строкой.

daoImpl=hibernate # choose hibernate implementations.

Теперь daoImpl будет заменен на "hibernate". Другое преимущество этого метода заключается в том, что SpringPropertyPlaceHolder может также получать свойства из среды, которые он может использовать в предпочтении к app.properties (зависит от параметра конфигурации, смотрите подробности в javadocs)

Следовательно, вы можете настроить поведение своего приложения, используя свойства среды, которые могут быть довольно мощными.

Альтернатива 2:

Вы также можете использовать профили Maven для достижения аналогичного поведения. Maven имеет возможность «фильтровать» ваши ресурсы - в этом случае он заменит заполнители на некоторые строки в зависимости от профиля maven, под которым он выполняется. Вы можете использовать эту функцию для генерации пакетов приложений (jar, уши и т. Д.), Которые работают с данной реализацией (например, hibernate, ibatis и т. Д.). Очевидно, что это менее гибкий подход, чем PropertyPlaceHolder, но может быть предпочтительным при определенных условиях.

1 голос
/ 16 июля 2010

Я бы сказал, что вы сильно упускаете суть, если думаете, что вам нужно написать фабрику. В этом случае контекст приложения Spring является фабрикой: декларативная, динамическая фабрика объектов. Классы, использующие вашу фабрику, теряют преимущество Spring.

Вы можете написать общий DAO, чтобы вам не приходилось поддерживать весь этот код.

package hibernate.policy.persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...