Представление В спящем режиме критерии через сервис API
Мне нужны были сертификаты только для Cygwin и git, поэтому я сделал то, что написал @esquifit. Однако мне пришлось выполнить шаг 5 вручную, c_rehash не был доступен в моей системе. Я следовал этому руководству: Установка сертификатов CA в платформу OpenSSL .
6 ответов
Реальное решение, которое я реализовал, использует гибридный подход.
Методы, которые используют четко определенные запросы (например, методы, которые используются внутри других служб, предопределенные отчеты и т. Д.), Имеют сигнатура, аналогичная методам findBy HibernateTemplate:
public List<Entity> findEntities(String queryName, QueryParameters parameters);
где QueryParameters - это вспомогательный класс для явного указания именованных параметров или получения их из bean-компонента. Пример использования:
List<Product> products = findProducts("latestUpdates",
new QueryParameters()
.add("vendor", "Oracle")
.add("price", "50.0")
);
или
List<Product> products = findProducts("latestUpdates",
new QueryParameters(product, "vendor", "price"));
Доступ к таким методам ограничен «доверенным» кодом; Очевидно, что используемые запросы должны быть определены в сопоставлениях Hibernate. Фильтры встроены в запрос или определены как фильтры сеанса. Преимущества заключаются в более чистом коде (отсутствие материалов, подобных критериям, разбросанных по половине страницы) и четко определенному HQL (легче оптимизировать и при необходимости работать с кешем).
Методы, которые доступны пользовательскому интерфейсу или должны быть более динамичными, используют интерфейс Search из проекта Hibernate-Generic-DAO . Он чем-то похож на DetachedCriteria Hibernate, но имеет несколько преимуществ:
Он может быть создан без привязки к конкретному объекту. Для меня это большое дело, потому что интерфейс сущности (часть API, видимая пользователям) и реализация (POJO, отображаемый в Hibernate) - два разных класса, и реализация недоступна пользователю во время компиляции.
Это хорошо продуманный открытый интерфейс ; в отличие от DetachedCriteria, из которого практически невозможно что-либо извлечь (да, я знаю, что DC не был предназначен для этого; но все же)
Встроенная разбивка на страницы / результаты с общим количеством / набор других мелких тонкостей.
Нет явной связи с Hibernate (хотя лично меня это особо не волнует; я не собираюсь внезапно отказываться от Hibernate и переходить на EclipseLink завтра); доступны как Hibernate, так и общие реализации JPA.
Фильтры могут быть добавлены в поиск на стороне службы; это когда также указывается класс сущности. Единственное, чего не хватает, это быстрого сбоя на стороне клиента, если указано недопустимое имя свойства, и это можно решить, написав мою собственную реализацию ISearch / IMutableSearch, но я еще не дошел до этого.
s, когда также указан класс сущности. Единственное, чего не хватает, это быстрого сбоя на стороне клиента, если указано недопустимое имя свойства, и это можно решить, написав мою собственную реализацию ISearch / IMutableSearch, но я еще не дошел до этого. s, когда также указан класс сущности. Единственное, чего не хватает, это быстрого сбоя на стороне клиента, если указано недопустимое имя свойства, и это можно решить, написав мою собственную реализацию ISearch / IMutableSearch, но я еще не дошел до этого.Вариант первый: Если есть возможность расширить ваш API, я предлагаю сделать ваш API «богаче» - добавить больше методов, таких как несколько ниже, чтобы ваш сервис звучал более естественно. Может быть сложно сделать ваш API больше, не создавая впечатление раздутого, но если вы последуете аналогичной схеме именования, это будет казаться естественным для использования.
productService.findProductsByName("Widget")
productService.findProductsByName(STARTS_WITH,"Widg")
productService.findProductsByVendorName("Oracle")
productService.findProductsByPrice(OVER,50)
Объединение результатов (применение нескольких ограничений) может быть оставлено для клиентов после того, как они получили набор результатов с помощью CollectionUtils и Predicates. Вы даже можете создать несколько общих предикатов для потребителей вашего API, чтобы быть вежливым. CollectionUtils.select () - это весело.
Вариант второй: Если невозможно расширить API, я бы выбрал третий пункт.
- Напишите свой собственный интерфейс / реализацию QueryCriteria, которая будет формируют либо DetachedCriteria, либо HQL за кулисами ...
Вы можете попробовать применить подход в стиле DSL к именованию, используя что-то вроде шаблона Builder, чтобы сделать вещи более читаемыми и естественными. Это становится немного неуклюжим в Java со всеми точками и скобками, но может быть что-то вроде:
Product.Restriction restriction = new Product.Restriction().name("Widget").vendor("Oracle").price(OVER,50) );
productService.findProducts(restriction);
Вариант третий: Объедините два подхода, предоставив критерии стиля ограничения вместе с более богатым API. Эти решения будут чистыми, поскольку они скрывают детали реализации Hibernate от потребителя вашего API. (Не то чтобы кто-нибудь когда-либо подумал бы о выходе из спящего режима.)
предоставление критериев стиля ограничения вместе с более богатым API. Эти решения будут чистыми, поскольку они скрывают детали реализации Hibernate от потребителя вашего API. (Не то чтобы кто-нибудь когда-либо подумал бы о выходе из спящего режима.) предоставление критериев стиля ограничения вместе с более богатым API. Эти решения будут чистыми, поскольку они скрывают детали реализации Hibernate от потребителя вашего API. (Не то чтобы кто-нибудь когда-либо подумал бы о выходе из спящего режима.)Хм - интересный вопрос.
Если подумать, возможно, лучше написать собственный интерфейс критериев. Это не привяжет вас к реализации и снизит проблемы безопасности.
Также в зависимости от того, сколько объектов задействовано, было рассмотрено возвращение всего набора продуктов (с примененными необходимыми фильтрами), а затем конечный пользователь применил фильтры с lambdaj или похожие. См .:
Никогда не стоит раскрывать такие детали реализации. С этого момента вы привязаны к этой библиотеке. Хуже того, любое изменение API библиотеки повлечет за собой изменение API вашей службы. Все соображения безопасности остались позади ...
Что насчет имен свойств bean-компонентов, используемых в критериях (тройка имени свойства, перечисление с меньшим, равным и большим и значением). С помощью оболочки bean-компонента в вашей модели вы можете преобразовать это в критерий гибернации.
Также будет возможно преобразовать эти имена свойств в новую версию после изменения модели.
Hibernate - это низкоуровневая инфраструктура инфраструктуры, и поэтому она должна оставаться скрытой за кулисами. Если в следующем месяце вашему приложению по какой-то причине потребуется переключиться на другую структуру ORM, ваш API будет бесполезен. Инкапсуляция даже между уровнями в одном приложении жизненно важна.
Сказав все это, я думаю, ваш метод должен получать абстракцию информации, необходимой для выполнения поиска. Я советую вам создать перечисление полей Product и реализовать одну или две простые версии Restriction.
Параметрами метода могут быть список ограничений равенства, другой список относительных ограничений и, конечно же, индикатор порядка (одно из значений перечисления плюс флаг для asc / desc).
Это просто общее направление
Я думаю, что запрос по примеру будет здесь очень хорошо работать.