Adds a Staffing repository following the pattern established with ConsultantRepository etc.
Due to heavy queries, this one also gets a layer of caching. Currently this is optimistic based on that current queries are always based on a Consultant, i.e. "All staffing for this consultant id".
Unlike previous refactors, this one also changes the logic a good bit:
Instead of one huge cache-entry for all the staffing, this now caches per consultant. More on this later.
The responsibility to join the data from the repo is now in the Controller layer. This should be in an Application layer, but I want to tackle this one thing at a time.
More on caching:
Since it's just one StaffingCacheRepository now, this can have more granular caching, with keys pr consultant.
This is to support the by far most common use-case: Getting Staffing for one or more consultants. Other use-cases in the future like Staffing pr project would just be forwarded to the DB-repository class.
This means that we don't need to re-fetch everything when staffing changes. More on this in performance.
Will this hurt performance?
Yes and no.
The initial call, which first populates the DB is slower:
ca. 7-800ms before, vs 900-1.000 ms now
Loading with no changes is about the same:
10-80ms before, vs 20-40 ms now
With some changes to staffing, this is faster though:
ca. 3-400ms before, vs ca. 150ms now
Todos
To avoid scope-creep, here are some TODOs left. These are mainly there due to a lacking Application-layer, which we should add soon.
Adds a Staffing repository following the pattern established with ConsultantRepository etc.
Due to heavy queries, this one also gets a layer of caching. Currently this is optimistic based on that current queries are always based on a Consultant, i.e. "All staffing for this consultant id".
Unlike previous refactors, this one also changes the logic a good bit:
More on caching:
Since it's just one StaffingCacheRepository now, this can have more granular caching, with keys pr consultant. This is to support the by far most common use-case: Getting Staffing for one or more consultants. Other use-cases in the future like Staffing pr project would just be forwarded to the DB-repository class.
This means that we don't need to re-fetch everything when staffing changes. More on this in performance.
Will this hurt performance?
Yes and no. The initial call, which first populates the DB is slower: ca. 7-800ms before, vs 900-1.000 ms now
Loading with no changes is about the same: 10-80ms before, vs 20-40 ms now
With some changes to staffing, this is faster though: ca. 3-400ms before, vs ca. 150ms now
Todos
To avoid scope-creep, here are some TODOs left. These are mainly there due to a lacking Application-layer, which we should add soon.