How should we deal with the growing repository in model layer?

In the todo project we simply have one POJO(Task) and we already have a bloated model layer here. It’s quite common to have dozens of POJOs in a REAL project. And it’s easy to imagine how big the repository would grow. Whenever I want to add amend something, like adding a Owner(of a Task), I have to add so many lines of code in each one of the classes in the model layer. No need to mention that we have to write so many hardcoded SQL statements. Is there a better way to avoid these things?

[HarlonWang]

Thanks for reply @PopTudor , it’s very helpful to me .

[ryanhoo]

@PopTudor @81813780 Sorry for later answer. 😅

I think it’s better to define the method in the Contract interface.

Why?

Interface is the standard that it defines protocols for implementations to follow. Also, for those who wants to communicate with this, the methods in interface are accountable because you know they will be implemented.

In view-presenter layer we use xxxContract.View to hold the reference instead of using xxxFragment directly.

I got the inspiration from the View-Presenter-Contract, instead of drafting a single contract for both Repository, LocalDataSource, RemoteDataSource to follow(which is a little bit annoying). My contract is like this:

interface UserContract {

   interface Local {
       Observable<User> user();

       // database only
       boolean update(User user);
       boolean delete(User user);
       ...
  }

  interface Remote {
       Observable<User> user();
  }

  Observable<User> user(boolean forceUpdate);
}

And then I implement LocalUserDataSource to handle local db operations, RemoteUserDataSource to handle network request. And finally our UserRepository comes:

class UserRepository {

   UserContract.Local mLocalDataSource;
   UserContract.Remote mRemoteDataSource;

   private UserRepository() {
      mLocalDataSource = new LocalUserDataSource(Injection.provideDbHelper());
      mRemoteDataSource = new RemoteUserDataSource(Injection.provideRESTfulApi());
   }

   public static UserRepository getInstance(){
      ...
   }

   public Observable<User> user(boolean forceUpdate) {
      Observable<User> local = mLocalDataSource.user();
      Observable<User> remote = mRemoteDataSource.user()
                  .doOnNext(user -> mLocalDataSource.save(user));
      if (forceUpdate)
            return remote;
      return Observable.concat(local, remote).first();
   }
}

I wanted to separate the contract into three parts is because they behave differently, both local & remote datasource should only handle their own business.

But if we simply define them in a single contract, it will just add more constraints to our code and brings more confusion to your reviewers. How are you going to implement deleteUser in remote datasource? Yes of course you can just leave it alone. Once I even added @Dreprecated annotations to those empty implementations. LOL

And finally for you confusion:

If you need to expose more methods to presenters, just add it in Contract and then implement it.