Преимущества шаблона хранилища и реализация Spring

Question

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

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

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

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

НО, если вы хотите взглянуть на Spring's accessing data JPA guide, вы найдете следующий код:

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 заставляет нас добавлять новые методы для взаимодействия?

Answer 1

Моего вывод представляется - хранилище картина лучше, чем DAO из-за его интерфейсов закрыты для модификации

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

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

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 - это 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 { 
… 
} 

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

Edit: ответ на комментарий

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