Composing Structured Queries with Repositories

[MrSkwiggs]

I'm trying to follow the recently posted episode 348's approach with task loading, but I'm not sure how to define what my repos should return for this observation.

Consider the following example of a SOLID app architecture where models are vended through repositories;

@Table
struct Player {
  let id: String
  let name: String
  let score: Int
}

protocol PlayerRepository {
  func all() throws -> [Player]
  func increaseScore(of player: Player) throws
  func observable() -> ?
}

and the following view & view model:

struct PlayersView: View {
  @State
  var model: Model

  var body: some View {
    Form {
      ForEach(model.player) { player in 
        HStack {
          Text(player.name)
          Spacer()
          Text("Score: \(player.score)")
          Button {
            model.userDidTapPlayerScoreButton(for: player)
          } label: {
            Text("Add point")
          }
        }
      }
    }
    .task {
      try await model.task()
    }
  }
}

extension PlayersView {
  @Observable
  final class Model {
    let repo: any PlayerRepository
    
    @ObservationIgnored @FetchAll
    var players: [Player]

    init(repo: any PlayerRepository) {
      self.repo = repo
    }

    func userDidTapPlayerScoreButton(for player: Player) {
      withErrorReporting {
        try repo.increaseScore(of: player)
      }
    }

    func task() async {
      withErrorReporting {
        try await $players.load(repo.observable).task
      }
    }
  }
}

In a concrete implementation of such a repository, I could then return this for func observable():

struct MainPlayerRepository: PlayerRepository {
  ... 

  func observable() -> ? {
    Player.all.order { $0.score.desc() }
  }
}

But I'm not sure what type I should return, in a generic way. Is there a some Query I could use?

Or more generally, is there a better way to work with SOLID here? My main goal is to not depend on the DB in my app/UI layer...

[mbrandonw]

Hi @MrSkwiggs, if you are wanting the type of query that can be loaded into @FetchAll, then you can use Statement:

func observable() -> any Statement<Player>

However, I'm not really sure what your abstraction is buying you. First, you still have to use @FetchAll in the model, and so you're not really insulating yourself from the APIs of the library. And that is just something that you will have to live with because there is no way to abstract away that tool.

And second, what would another conformance of PlayerRepository even look like? Typically these kinds of protocols are to make code more testable so that you can provide test-friendly implementations in tests. But in the case of SQLite there's no need to do that. You can interact directly with SQLite's APIs in tests just fine because you have the option of running an in-memory database that is quarantined from all other tests running.

So, I would take a hard look at whether or not this abstraction is really worth the effort,

[MrSkwiggs]

Thanks for the reply 🙏

Yeah I'm... not entirely sure whether I'm mixing too many things just for the sake of following SOLID principles... It has significantly slowed down my work trying to learn SQLiteData, CloudKit while trying to maintain clear domain boundaries :/

[MrSkwiggs]

Although, with that said;

I do have a use for them, in that I can provide basic CRUD operations to other services in my app (i.e a bootstrap service that creates the initial data on first launch). That way I don't need to always depend on defaultDB, and re-implement sensitive operations where I can't rely on FKs because CloudKit :D

But yea... making them protocols is most likely overkill

[mbrandonw]

Yeah, there are other ways to share operations and queries like that other than protocols. And the library (and even SQL) comes with lots of tools to aid in that.

[MrSkwiggs]

Would you have pointers for me for such tools? 🙏 I'm still figuring a lot of things out and this sounds exactly like what I'd need

[mbrandonw]

Well, at a very base level you can always encapsulate shared units of work in simple Swift functions.

Then for reusable queries you can see the docs here. And SQLite has a concept known as triggers which can allow you to listen for any changes happening in the database. And finally, database views are a great way to bundle up complex queries into a package that is queryable on its own.

All of those tools together for a very robust foundation for building complex persistence systems that can be interacted with simply.