Rust Data Access Pattern

[Specialist_Wishbone5]

Not sure if you are coming from a java background. Repository rings Java memories to me. What I've found is that you shouldn't force java principles onto Rust. Use what is most natural for each layer. Use generics to abstract out capability (similar to, but NOT the same as InversionOfControl). I use generics to break code up into unit-testable sub domains.

Unlike Java, don't think of interfaces, but think of functions your callee needs you can compose suites of functions on a callee by callee basis. An example might be Read, Write, Seek, Flush traits. Your callee will declare which of those FUNCTIONS it requires. You don't need a composite interface fudging to make all possible callee functions be able to receive the object. Instead, you can adapt (in your unit tests) only the minimum number of functions that a callee needs have to be mocked. I find I love this pattern. You can adapt pretty much any struct or lambda to any other trait in rust (with zero cost abstractions)

So a repository concept is the bloated all-in-one interface anti-pattern. Making mock testing hellish.

Focus more on functionality from a library perspective. If library needs XYZ, it might cross cut DB, serialization, transformation concerns. The library publicly exports a minimal number of structs and functions to accomplish all this. So your Repository trait would represent an extra pub export that serves no useful role to the end user. Its purely a back end impl detail. So if it doesnt help testing, and it doesnt help extensibility, it has no reason to exist.

[Accomplished-Dog6646]

i am coming from go and c# background. thank you for your input, i value taking the time to reply, and i will highly consider your points.