2012-06-29 2 views
1

Следующий код не работает (конечно), потому что отмеченная строка не компилируется:Spring + Монго + Дженерики + Гибкость

MyClass { 
    //singleton stuff 
    private static MyClass instance; 
    private MyClass() {} 
    public static MyClass getInstance() { 
     if(instance==null) { 
      instance = new MyClass(); 
     } 
     return instance; 
    } 

    // method creating problems 
    public NonGenericSuperClassOfGenericClass create(Class<?>... classes) { 
     if(someCondition) 
      return new GenericClass<classes[0],classes[1]>; // DOES NOT COMPILE 
     else 
      return new OtherGenericClass<classes[0]>; 
    } 
} 

Поэтому я на самом деле не знаю, является ли «создать» будет вернуться

GenericClass<classes[0],classes[1]> 

или

OtherGenericClass<classes[0]> 

, которые имеют различное число параметров.

Это происходит потому, что я использую Spring, и я планирую использовать MongoDB, но в будущем я, возможно, придется переключиться на что-то другое (например, спящий режим).

Класс GenericClass это что-то вроде:

GenericClass<PersistetType1, Long> 

или

GenericClass<PersistentType2, Long> 

где PersistentType1/2 классы, что мне нужно, наконец, хранить в БД, в то время, GenericClass является своего рода прокси для доступа к API Mongo. На самом деле это выглядит так:

public MongoTemplate getTemplate(); 
    public void save(T toInsert); 
    public List<T> select(Query selectionQuery); 
    public T selectById(ID id); 
    public WriteResult update(Query selectionQuery, Update updatedAttributes); 
    public void delete(T toRemove); 
    public void delete(Query selectionQuery); 

Теперь, что? Из контроллеров (или Entity, если вы придирчивы) Мне нужно создать экземпляр репозитория и вызвать любые методы. Это приводит к тому, что контроллеры соединяются с MongoDB, т. Е. Они явно должны создавать экземпляр такого GenericClass, который на самом деле называется MongoRepository и строго зависит от Mongo (на самом деле он является общим с ровно двумя «степенями свободы»).

Итак, я решил создать MyClass, это еще один прокси-сервер, который изолирует контроллеры. Таким образом, контроллер может получить единственный экземпляр MyClass и создать новый экземпляр соответствующего репозитория. В частности, когда «somecondition» истинно, это означает, что мы хотим использовать MongoRepository (когда это ложно, возможно, необходимо создать экземпляр Hibernate proxy, то есть HibernateRepository). Однако MongoRepository является общим, поэтому он требует некоторой формы инстанцирования, которую я надеялся передать в качестве параметра.

К сожалению, дженерики разрешены во время компиляции, поэтому они не работают для меня, я думаю.

Как это исправить?

ответ

2

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

Определите интерфейс вашего DAO с помощью необходимых методов, например. сохранить, обновить и т. д. И затем предоставить реализацию для каждого провайдера персистентности, который может вам понадобиться. Например, UserAccess может быть интерфейсом, который вы можете реализовать как HibernateUserAccess и MongoUserAccess. В каждой реализации вы вводите соответствующий шаблон, например. Mongo или Hibernate и использовать это для завершения операции сохранения.

Возможно, проблема заключается в том, что ваша операция загрузки вернет экземпляр пользователя, это должно варьироваться в зависимости от поставщиков персистентности, т. Е. Аннотации JPA будут отличаться от аннотаций Spring Data, необходимых для MongoDB (нечеткая абстракция).

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

+0

Конечно, это решение, но для этого потребуется, чтобы я реализовал DAO для каждого постоянного объекта. Я не хочу этого делать, поскольку это требует больших усилий, в то время как вероятность переключения настойчивости обеспечивается довольно низкой. Я предпочел бы сохранить свои 20/25 сущности вместе с MongoDB и играть на не меняющемся провайдере. – Manu

+0

Тогда я бы это сделал. Изменение поставщика постоянства - это не то, что часто случается. Конечно, усилия, связанные с обновлением 25 объектов, в любом случае не так велики. –

Смежные вопросы