My scenario is an application that allows for different databases to be used for the datastore, one being Elastic and one being SQLite its beyond abstracting at the SQL layer, and it seems like traits for these datastore structs might make sense, but am curious if I'm missing a better option.. Basically what I'm looking at..
struct SQLiteDataStore {
// Connection, and some basic methods for working with the datastore.
}
struct ElasticDataStore {
// Connection, basic methods for working with the datastore.
}
And then an enum
that is part of my shared state object that is passed to all my web handlers (this is an axum based app):
enum Datastore {
SQLite(SQLiteDataStore),
Elastic(ElasticDataStore),
}
/// The shared state passed to all route handlers.
struct SharedState {
pub datastore: Datastore,
....
}
So one service might be a StatsService
that generates a report from the datastore.
trait StatsService {
async fn stats_by_agent(&self, ...) -> Result<...>;
}
And then implement that for each datastore, or even on the enum so my router handlers don't concern themselves with the type of datastore at all.
I had first started by adding all the things I might do with a datastore in the datastore impl itself, but thats getting a bit bloated as the application grows.
Thanks for any ideas or comments on this type of structure.