В приложении для Android, которое я создаю, я инкапсулирую реляционные запросы в слой модели.
Один из моих объектов, назовем его Place
, имеет многозначное свойство (назовем его Image
). Упрощенно я могу сказать, что модель в Java выглядит следующим образом:
class Place{
List<Image> images;
...
}
class Image {
String description;
String imageName;
...
}
В базе данных эти классы отображаются в таблицы PLACE и IMAGE.
На стороне Java я использую DAO для запроса, вставки, обновления и удаления Place
объектов.
В качестве упрощенного примера я хотел бы иметь класс с именем PlaceDataSource
, который выглядит следующим образом:
class PlaceDataSource {
public List<Place> findAll();
public void update(Place place);
public void add(Place place);
public void delete(Place place);
...
}
Описание этих методов следующее:
Метод findAll
отвечает на список Place
с, каждый из которых содержит коллекцию Image
объектов.
Метод update
обновляет Place
и его изображения (обновление, вставка новых изображений или удаление существующих изображений при необходимости).
Метод add
добавляет новый Place
со своими изображениями.
Метод delete
удаляет Place
со всеми его изображениями.
Методы findAll
, add
и delete
очень легко реализовать.
Однако я не видел простого способа реализации метода update
, который учитывает многозначное свойство. Мне приходит в голову процедурный алгоритм:
- Запрос из базы данных текущих сохраненных изображений из объекта
Place
для обновления.
- Узнайте, какие
Image
объекты больше не присутствуют в свойстве images
объекта Place
и удалите их.
- Обновите сохраненные изображения, которые существуют в свойстве
images
.
- Добавление новых изображений, присутствующих в свойстве
images
.
Я думаю, что этот код будет уродливым и неэффективным.
Есть ли лучший способ реализовать DAO?
В ваших приложениях, использующих DAO, вы предпочитаете, чтобы каждый DAO всегда отображался на одну физическую таблицу?
Я думал об использовании двух разных DAO в этом сценарии, один для сохранения Place
объектов и другой для Image
объектов. Тогда Place
DAO не будет нести ответственность за постоянство объектов изображений, а «бизнес» уровень должен поддерживать их согласованность.
Тем не менее, Image
являются концептуально частью Place
объектов, поэтому это решение не полностью меня убедило.
Большое спасибо за отзыв!
Примечание: в настоящее время я не заинтересован в использовании платформы ORM для Android, просто хотел бы найти ответ на эту проблему с концептуальной точки зрения.