Блог

В статье Не используйте DAO, используйте репозиторий есть довольно хорошее объяснение различий между шаблонами DAO и репозиториев.

Мой краткий пересказ — DAO заставляет нас раздувать интерфейс множеством методов, которые препятствуют изменениям и тестированию. В свою очередь, репозиторий инкапсулирует все настройки / изменения с query помощью метода, который принимается Specification в качестве аргумента. Когда вам нужно новое поведение в репозитории — вы не должны его изменять, вместо этого создайте нового наследника Specification .

Мой шаблон conslusion — repository лучше, чем DAO, потому что его интерфейсы закрыты для модификации.

Я прав до сих пор? Разве я не пропустил некоторые преимущества шаблона репозитория?

НО, если вы посмотрите на руководство Spring по доступу к данным JPA, вы найдете следующий код:

 public interface CustomerRepository extends CrudRepository<Customer, Long> {
    List<Customer> findByLastName(String lastName); //each time you need custom behavior you need to add a method
    //...
}
 

Разве это не противоречит предыдущей статье? Почему репозиторий Spring заставляет нас добавлять новые методы в интерфейс?

Мой шаблон conslusion — repository лучше, чем DAO, потому что его интерфейсы закрыты для модификации

Это зависит от …
Потому что шаблон репозитория более сложный, поскольку требует больше кода для написания и имеет более высокий уровень абстракции, чем шаблон DAO, как для клиентов репозитория, так и для его реализации.
Когда вам нужна гибкость в ваших запросах и / или ваши запросы смешивают несколько объектов в результате, шаблон репозиторияможет удовлетворить эти потребности. Если вам нужно выполнять в основном простые операции crud над таблицей (базовые операции создания, чтения, обновления и удаления), я думаю, что использование реального репозитория (например, со спецификациями) может быть накладным.

НО, если вы посмотрите на руководство Spring по доступу к данным JPA, вы найдете следующий код:

  public interface CustomerRepository extends CrudRepository<Customer,Long> {
    List<Customer> findByLastName(String lastName); //each time you need custom behavior you need to add a method
     //... }
 

Разве это не противоречит предыдущей статье? Почему
репозиторий Spring заставляет нас добавлять новые методы в интерфейс?

ДА. Я думаю, что проблема возникает из Spring, которая использует модный термин (репозиторий) для обозначения класса, который не является репозиторием в соответствии с шаблонной литературой. (http://martinfowler.com/eaaCatalog/repository.html )
Я думаю, вам следует рассматривать Spring Repository как DAO, поскольку базовым функциональным интерфейсом Spring repository является CrudRepository. И по своей природе операции CRUD — это операции, которые мы находим в DAO…

После этого ничто не мешает вам обогатить репозиторий, чтобы предоставить методы репозитория со спецификациями Spring, как в пункте 2.4 официальной документации Spring data.
Spring предлагает вам расширить org.springframework.data.repository.CrudRepository интерфейс, как в вашем примере. Это самый простой способ сделать, и я полагаю, что это самый распространенный способ сделать…

 public interface CustomerRepository extends CrudRepository<Customer, Long>, JpaSpecificationExecutor {
 …
}
 

И JpaSpecificationExecutor предоставляет методы, которые используют спецификации и, следовательно, способствуют сокращению повторяющихся обработок в исходном коде запросов :

 /*
 * Copyright 2008-2011 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.springframework.data.jpa.repository;

import java.util.List;

import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.data.domain.Sort;
import org.springframework.data.jpa.domain.Specification;

/**
 * Interface to allow execution of {@link Specification}s based on the JPA criteria API.
 * 
 * @author Oliver Gierke
 */
public interface JpaSpecificationExecutor<T> {

    /**
     * Returns a single entity matching the given {@link Specification}.
     * 
     * @param spec
     * @return
     */
    T findOne(Specification<T> spec);

    /**
     * Returns all entities matching the given {@link Specification}.
     * 
     * @param spec
     * @return
     */
    List<T> findAll(Specification<T> spec);

    /**
     * Returns a {@link Page} of entities matching the given {@link Specification}.
     * 
     * @param spec
     * @param pageable
     * @return
     */
    Page<T> findAll(Specification<T> spec, Pageable pageable);

    /**
     * Returns all entities matching the given {@link Specification} and {@link Sort}.
     * 
     * @param spec
     * @param sort
     * @return
     */
    List<T> findAll(Specification<T> spec, Sort sort);

    /**
     * Returns the number of instances that the given {@link Specification} will return.
     * 
     * @param spec the {@link Specification} to count instances for
     * @return the number of instances
     */
    long count(Specification<T> spec);
}
 

Но я думаю, что это создаст существо Франкенштейна: наполовину DAO, наполовину репозиторий.

Другим решением является непосредственная реализация базового и маркерного интерфейса: org.springframework.data.repository.Repository и JpaSpecificationExecutor подобного интерфейса :

 public interface CustomerRepository extends Repository<Customer, Long>, JpaSpecificationExecutor {
 …
}
 

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

Редактировать : ответ на комментарий

Шаблон репозитория — это концепция, которую Hibernate не предоставляет с готовым решением.
Но Hibernate и, в более общем плане, спецификация JPA 2 предоставляют критерии indeed в качестве основного компонента для создания спецификаций в виде классов.
Затем вы можете создать пользовательский класс, который реализует шаблон репозитория, предлагая требуемые методы со спецификациями в качестве входных данных. Я думаю, вы можете использовать ORM и репозитории, поскольку вы можете использовать ORM со спецификациями, используя criteria API. Некоторые люди выступают против ORM и репозитория, и я не согласен. ORM не основан на шаблоне DAO. DAO — это способ манипулирования данными в базе данных. ORM — это способ структурирования объектов данных для представления структур базы данных. Например, используя оба варианта, вы можете извлечь выгоду как из гибкости спецификаций, так и из возможностей сопоставления реляционных объектов и взаимодействия между сущностями.
Если вы не используете ORM или ORM, подобные iBatis, вам следует самостоятельно закодировать то, что предлагает вам ORM: объектно-реляционное сопоставление.