Как реализовать одно-много отношений в чистой архитектуре

Question

У меня проблемы с использованием чистой архитектуры. Для тех из вас, кто прочитал сообщение блога Fernando Cejas http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/, мой вопрос основан на нем и его коде.

В своем примере проект имеет только один объект Domain a User. И все понятно с POJO. Там, где у меня проблема, скажем, что у пользователя есть книги. От одного до многих отношений. Как бы вы справились с этим в «Чистой архитектуре»?

Как и у меня, у меня есть несколько слоев, поэтому по 3 классам для объекта домена (User, UserModel, UserEntity) и репозитория на объект домена (UserDataRepository). Наш новый пример также будет иметь Book, BookModel, BookEntity и BookDataRepository.

У меня также есть классы использования с вариациями CRUD.

Проблема для меня - это уровень UI/Presenter. На данный момент в программе у меня есть объект UserModel AND список BookModels. У меня нет userModel.getBooks(). У меня нет userModel.save() (который также сохранил бы все изменения в книге).

Чтобы подчеркнуть проблему, чтобы сделать эту аналогию более похожей на мой фактический прецедент, у меня также есть список всех страниц в книгах! :) Поэтому, когда я сохраняю пользователя, я хочу сохранить книги и все страницы для каждой книги, которая могла быть изменена.

Как бы я это сделал?

Второй вопрос BONUS: В моей реальной проблеме, я имею классы, которые происходят из базового класса. Чтобы использовать вышеупомянутую аналогию: LeftPage и RightPage будут получены из PageBase. У книги есть список. Однако у LeftPage и RightPage есть свои отдельные репозитории, отдельные варианты использования и т. Д. (Но это не работает) Как сохранить список? Должен ли я сделать отдельный SavePages прецедентов, которые будут иметь:

если (pages.elementAt (я) InstanceOf LeftPage) { SaveLeftPage saveLeft = новый ..... } еще { SaveRightPage saveRight = новый ..... }

Я не думаю, что могу использовать полиморфизм, потому что во всей документации, которую я видел, модели не знают о случаях использования.

Я надеюсь, что вы можете помочь, спасибо вам большое за ваше время :)

-Mike

Answer 1

Это Uncle Bob's Clean Architecture. Фернандо Сеяс сделал упрощенный пример в Android, но вы должны прочитать концепции из оригинала.

Для вашей проблемы, что на самом деле ваш прецедент? Сохранить пользователя с книгами и страницами? Вы можете это сделать, если это требования использования. Ваша сущность Пользователь может иметь коллекцию книг, в свою очередь каждая книга будет иметь коллекцию страниц, а ваш UserRepository должен иметь возможность разрешать каждую свою собственную таблицу (или вы можете вводить репозитории в свои собственные репозитории, но в этом случае вы должны быть в состоянии сохранить все или откат)

Можете ли вы сохранить книгу только с помощью ссылки на пользователя? Имейте свойство, которое идентифицирует владельца книги или передает его аргументом в UseCase только для книги.

 public class SaveBookCase extends UseCase 
     { 
      public SaveBookCase(IBookRepository repository, Book book, int userId) 
      { 
      /// 
      } 

      //or 

      public SaveBookCase(IBookRepository repository, SaveBookRequest request) 
      { 
      /// SaveBookRequest is a class that has the book and the user id 
      } 
     } 

Что касается вашего второго бонусного вопроса, если у вас есть только список PageBase, чем вы должны передать его в USECASE SavePages, который будет решать каждый элемент в правильное хранилище (в этом случае вы будете вводить 2 репозиториев) ,

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