Недавно я создал продюсера oData с использованием Olingo и обнаружил, что я так же расстроен. Я думаю, что часть проблемы заключается в том, что существует много разных способов создания oData-сервиса с Olingo, а часть доступа к данным полностью зависит от разработчика, чтобы разобраться в своем собственном проекте.
Во-первых, вам необходимо приложение, в котором установлено соединение с базой данных. Поэтому, полностью игнорируя Olingo, у вас должно быть приложение, которое подключается и может запрашивать базу данных. Если вы не уверены в том, как создать Java-приложение, которое может запросить источник данных MySQL, вам следует использовать Google для учебных руководств, связанных с этой проблемой, и не имеет ничего общего с Olingo.
Далее вам нужно написать методы и запросы для выполнения операций CRUD в вашем приложении. Опять же, эти методы не имеют ничего общего с Олинго.
Где Olingo начинает играть, это ваша реализация классов процессоров. EntityCollectionProcessor
, EntityProcessor
и т.д. (обратите внимание, что существуют и другие проблемы, такие как настройки вашего CsdlEntityTypes и схемы/Service документа и т.д., но это выходит за рамки вашего вопроса)
Давайте начнем с рассмотрения EntityCollectionProcessor
. Внедряя класс EntityCollectionProcessor
, вам необходимо переопределить функцию readEntityCollection()
. Целью этой функции является анализ URI OData для имени сущности, выборка EntityCollection
для этого Entity
, а затем сериализация EntityCollection
в ответ, соответствующий требованиям OData. Вот реализация readEntityCollection()
из вашего примера ссылка:
public void readEntityCollection(ODataRequest request, ODataResponse response, UriInfo uriInfo, ContentType responseFormat)
throws ODataApplicationException, SerializerException {
// 1st we have retrieve the requested EntitySet from the uriInfo object
// (representation of the parsed service URI)
List<UriResource> resourcePaths = uriInfo.getUriResourceParts();
UriResourceEntitySet uriResourceEntitySet = (UriResourceEntitySet) resourcePaths.get(0);
// in our example, the first segment is the EntitySet
EdmEntitySet edmEntitySet = uriResourceEntitySet.getEntitySet();
// 2nd: fetch the data from backend for this requested EntitySetName
// it has to be delivered as EntityCollection object
EntityCollection entitySet = getData(edmEntitySet);
// 3rd: create a serializer based on the requested format (json)
ODataSerializer serializer = odata.createSerializer(responseFormat);
// 4th: Now serialize the content: transform from the EntitySet object to InputStream
EdmEntityType edmEntityType = edmEntitySet.getEntityType();
ContextURL contextUrl = ContextURL.with().entitySet(edmEntitySet).build();
final String id = request.getRawBaseUri() + "/" + edmEntitySet.getName();
EntityCollectionSerializerOptions opts = EntityCollectionSerializerOptions.with().id(id).contextURL(contextUrl).build();
SerializerResult serializerResult = serializer.entityCollection(serviceMetadata, edmEntityType, entitySet, opts);
InputStream serializedContent = serializerResult.getContent();
// Finally: configure the response object: set the body, headers and status code
response.setContent(serializedContent);
response.setStatusCode(HttpStatusCode.OK.getStatusCode());
response.setHeader(HttpHeader.CONTENT_TYPE, responseFormat.toContentTypeString());
}
Вы можете игнорировать (и повторного использования) все, в этом примере для «2» шаг за исключением:
EntityCollection entitySet = getData(edmEntitySet);
Эта строка кода где Olingo наконец начинает взаимодействовать с нашей базовой системой, а шаблон, который мы видим здесь, информирует о том, как мы должны настраивать остальные наши операции CRUD.
Функция getData(edmEntitySet)
может быть любой, что вы хотите, в любом классе, который вы хотите. Единственным ограничением является то, что он должен вернуть EntityCollection
. Итак, вам нужно вызвать функцию, которая запрашивает вашу базу данных MySQL и возвращает все записи для данного объекта (с использованием имени строки объекта). Затем, как только у вас есть список или набор (или что-то еще) ваших записей, вам необходимо преобразовать его в EntityCollection
.
В стороне, я думаю, что это, вероятно, происходит, когда происходит разрыв между примерами Olingo и реальным миром. Код позади этого getData(edmEntitySet);
вызова может быть спроектирована в бесконечно по-разному, в зависимости от характера конструкции, используемой в базовой системе (MVC и т.д.), выбор стайлинга, требования к масштабируемости и т.д.
Вот пример того, как я создал EntityCollection
от List
что вернулся из моего запроса (имейте в виду, что я предполагаю, что вы знаете, как опрашивать источник данных MySQL и уже закодированы функцию, которая извлекает все записи для данного объекта):
private List<Foo> getAllFoos(){
// ... code that queries dataset and retrieves all Foo records
}
// loop over List<Foo> converting each instance of Foo into and Olingo Entity
private EntityCollection makeEntityCollection(List<Foo> fooList){
EntityCollection entitySet = new EntityCollection();
for (Foo foo: fooList){
entitySet.getEntities().add(createEntity(foo));
}
return entitySet;
}
// Convert instance of Foo object into an Olingo Entity
private Entity createEntity(Foo foo){
Entity tmpEntity = new Entity()
.addProperty(createPrimitive(Foo.FIELD_ID, foo.getId()))
.addProperty(createPrimitive(Foo.FIELD_FOO_NAME, foo.getFooName()));
return tmpEntity;
}
Только для дополнительной ясность, getData(edmEntitySet)
может выглядеть так:
public EntityCollection getData(String edmEntitySet){
// ... code to determine which query to call based on entity name
List<Foo> foos = getAllFoos();
EntityCollection entitySet = makeEntityCollection(foos);
return entitySet;
}
Если вы можете найти пример Olingo, который использует класс DataProvider, есть некоторые основные примеры того, как вы можете настроить // ...code to determine which query to call based on entity name
. Я закончил тем, что модифицировал этот шаблон с использованием Java-отражения, но это совершенно не связано с вашим вопросом.
Так getData(edmEntitySet)
это функция, которая принимает имя лица, запрашивает источник данных для всех записей этого объекта (возвращающего List<Foo>
), а затем преобразует что List<Foo>
в EntityCollection
. EntityCollection
производится путем вызова функции createEntity()
, которая принимает экземпляр моего объекта Foo
и превращает его в Olingo Entity
. Затем EntityCollection
возвращается в функцию readEntityCollection()
и может быть правильно сериализована и возвращена как ответ oData.
В этом примере представлена небольшая проблема архитектуры, которую имеет Olingo с собственными примерами. В моем примере Foo - это объект, который имеет константы, которые используются для идентификации имен полей, которые используются Olingo для создания схемы oData и служебного документа. У этого объекта есть способ вернуть его собственный CsdlEntityType
, а также конструктор, его собственные свойства и геттеры/сеттеры и т. Д. Вам не нужно настраивать систему таким образом, но для требований к масштабируемости моего проекта это так Я решил сделать что-то.
Это общий шаблон, который использует Olingo. Переопределите методы интерфейса, затем вызовите функции в отдельной части вашей системы, которые будут взаимодействовать с вашими данными желаемым образом. Затем преобразуйте данные в Olingo, чтобы читать объекты, чтобы они могли делать все, что нужно «oData stuff» в ответе. Если вы хотите реализовать CRUD для одного объекта, то вам необходимо реализовать EntityProcessor и его различные методы CRUD, и внутри этих методов вам нужно вызвать функции в вашей системе (полностью отделенные от любого кода Olingo), которые create()
, read()
(единый объект), update()
, или delete()
.