Hi,
I'm writing a web API with warp and, coming from a Java background, I have multiple "services" (structs that impl Traits) which I want to combine.
I got it running using generics but the code is somehow now that readable
#[async_trait]
pub trait CalendarService: Send + Sync {
async fn insert() -> Option<Calendar>;
}
pub struct CalendarSVC<Repo: CalendarRepository> {
repo: Arc<Repo>,
}
impl<Repo: CalendarRepository> CalendarSVC<Repo> {
pub fn new(repo: Arc<Repo>) -> Self {
CalendarSVC { repo }
}
}
#[async_trait]
impl<Repo: CalendarRepository> CalendarService for CalendarSVC<Repo> {
async fn insert() -> Option<Calendar> {
None
}
}
In this simple case I only needed one parameter, I wonder how it might look if I needed multiple such "services"
on the other hand I could use a trait object
#[async_trait]
pub trait CalendarService: Send + Sync {
async fn insert(&self) -> Option<Calendar>;
}
pub struct CalendarSVC {
repo: Arc<dyn CalendarRepository>,
}
impl CalendarSVC {
pub fn new(repo: Arc<dyn CalendarRepository>) -> Self {
CalendarSVC { repo }
}
}
#[async_trait]
impl CalendarService for CalendarSVC {
async fn insert(&self) -> Option<Calendar> {
None
}
}
That looks way cleaner and more concise.
I remember I did this because of performance implications that I do not remember anymore. That said I don't know if that perfomance gain could be worth the extra hassle.
Can you enlighten me what gains there may be? All this is for learning purposes and might never see the light of day or might only be used by very few people.
One other aspect is: it is very likely all those services will only have static functions and there is no need to use &self in funtion calls other than for accessing other services. That would not be needed If I used generics.
There are tradeoffs to be made. What would be the more rusty way?
Thanks for your time