No Stupid Questions (Developer Edition)

923 readers

1 users here now

This is a place where you can ask any programming / topic related to the instance questions you want!

For a more general version of this concept check out [email protected]

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

LinearArray

Is preloading/caching data before the actual method call an (anti)pattern? (self.no_stupid_questions)

submitted 1 year ago by Cyno to c/no_stupid_questions

10 comments fedilink hide all child comments

cross-posted from: https://programming.dev/post/6513133

Short explanation of the title: imagine you have a legacy mudball codebase in which most service methods are usually querying the database (through EF), modifying some data and then saving it in at the end of the method.

This code is hard to debug, impossible to write unit tests for and generally performs badly because developers often make unoptimized or redundant db hits in these methods.

What I've started doing is to often make all the data loads before the method call, put it in a generic cache class (it's mostly dictionaries internally), and then use that as a parameter or a member variable for the method - everything in the method then gets or saves the data to that cache, its not allowed to do db hits on its own anymore.

I can now also unit test this code as long as I manually fill the cache with test data beforehand. I just need to make sure that i actually preload everything in advance (which is not always possible) so I have it ready when I need it in the method.

Is this good practice? Is there a name for it, whether it's a pattern or an anti-pattern? I'm tempted to say that this is just a janky repository pattern but it seems different since it's more about how you time and cache data loads for that method individually, rather than overall implementation of data access across the app.

In either case, I'd like to learn either how to improve it, or how to replace it.

you are viewing a single comment's thread
view the rest of the comments

[–] deceitfulsteve 3 points 1 year ago (2 children)

I work with a code base that is perhaps going through a similar transition. Performance hasn't really been a consideration and so when new functionality is tacked on we're frequently making a new API call even though we might already have the data somewhere else.

I don't have a name for the pattern or anti-pattern, but people's responses seem to indicate that it's largely a good thing, the change that you're making. I'm reminded of a Martin Fowler-esque or TDD idea that a function should either retrieve data or process it. However I wasn't able to find a blog post about that with a quick search.

[–] Cyno 2 points 1 year ago (1 children)

If you find or run into that article later please share it, I'd definitely like to read it!

[–] SwitchUp 3 points 1 year ago

Sounds like Command-Query Separation (CQS)

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.