2016-12-05 5 views
1

Похоже, что все используют аннотации для сохранения данных в настоящее время.Аннотация бесплатное решение для весенних данных

Почему это проблема?
Аннотации к сохранению специфичны для выбранного API персистентности. Если вы используете MySQL, вы используете @Entity, если используете Couchbase, вы должны использовать @Document.

В больших проектах обычно существует слой API, в котором моделируются объекты. Этот уровень имеет или, по крайней мере, не должен иметь никаких зависимостей от какой-либо конкретной базы данных.

public class User implements IUser { 
    private String email; 
    private String id; 
    private String password; 
    private String username; 

Так что здесь нельзя использовать @Document.

Параметр/сохранение уровня базы данных в настоящее время только этот репозиторий весна-данные

public interface IUserRepository extends CrudRepository<IUser, String> {} 

и класс по конфигурации

@Configuration 
@EnableCouchbaseRepositories 
class CouchbaseConfiguration extends AbstractCouchbaseConfiguration { 

Я ожидал найти пример конфигурации XML базы, но ничего, аннотации все над.
Как я могу решить эту проблему?
Существует ли подход, основанный на XML для сопоставления объектов?
Если нет, как это можно решить, не загрязняя API-слой?

+0

это скорее похоже на общий вопрос 'spring-data', так как проблема будет такой же, как и в других реализациях магазина, например' spring-data-jpa'? –

+0

Да, эта проблема также затрагивает другие реализации. Если, например, Hibernate можно использовать для баз данных SQL, моделирование может быть выполнено с помощью xml и без аннотаций в уровне API ... – Nabor

ответ

2

Для этого не существует подхода, основанного на XML. Если вам нужно полностью очистить свой уровень API, вам все равно нужно использовать конкретное хранилище и выбрать технологию в какой-то момент ... Таким образом, это будет означать, что вам нужно добавить слой между DTO API и то, что данные Spring сохраняются (юридические лица).

Обратите внимание, что данные Spring применяют различные соглашения к модели данных в зависимости от магазина. Для Couchbase аннотация @Document составляет не требуется, если вы не хотите иметь дело с истечения срока действия/TTL. Тем не менее, @Id аннотации еще обязательная (либо из SDK или Spring Data Общин, который я рекомендовал бы в вашем случае) ...

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

Spring Data Монго, кажется, обойтись без какой-либо аннотации, если вы будете следовать всем соглашениям (в частности, поле идентификатора было названы либо id или _id в сущности POJO), так что, возможно Spring Data Couchbase может быть изменен по умолчанию для такой конвенции для идентификатора, если идентификационная аннотация не найдена? (хороший PR-потенциал там ;-)

+1

Снова согласен, аннотации являются только декларативными, но они добавляют зависимости, которые могут не понадобиться в какой-то момент , Вы скоро достигнете ситуации, когда у вас есть аннотации для настойчивости вместе с аннотациями к JSON и т. Д. Я не думаю, что вам нужен дополнительный уровень между API и постоянством, если вы можете настроить сопоставление с аннотациями XML или микширования или хорошими стандартами по умолчанию предложенный вами.Все это можно сделать в слое persistence ... – Nabor