As Dotnet developers it’s very common to use ORMs like Entity Framework to work with databases. While it’s not the most performance tool, it’s extremely useful and flexible to use. With that it’s important to remember that the methods we use can change the performance of the query. Whether to use a Where followed by a FirstOrDefault or should we just use the FirstOrDefault? And what kind of query statement will either of these make?
After coding for a while and making more mistakes then anyone wants to admit we as programmers tend to create a spidey-sense of potential issues when doing code reviews. This is one of the primary reason we as an industry do code reviews. It’s commonly called “code smell” - when we see a pattern or code usage that seems off. A few months ago I ran into one of these and wanted to highlight the usage, because I see even experienced software engineers fall into this common practice. I would like to highlight that while good practice in theory is commonly agreed upon, people get lost in the details. That’s ok as long
One important aspect of managing data coming in through our api(s). Of course this is what data types and validation is for, but an easily overlooked aspect is handling strings and how we want store them in the database. It’s an easy oversight for anyone who hasn’t handle a large amount of data that is being used by multiple teams. An easy example is when two systems are comparing an email, but one system didn’t trim any white space and the user inputed their email with a space at the end. Sounds simple, right? It happens much more often then you’d think. We don’t want to add a lot of extra logic every time we compare strings to ensure there isn’t any white space unless absolutely necessary. Which is why it’s important to add logic to handle this on every request - which is pretty easy with Dotnet.
It’s been a couple years since I started this blog and there hasn’t been much progress. There is a couple different factors but the main one has been focus. I’ve been working Ritter Insurance Marketing since 2017. I started there a junior front end developer and in 2020 I moved over as a back end developer. Working primarily on back end services written in Dotnet. I started this blog a couple of years ago to try write down my thoughts and some experiences, but obviously didn’t keep up on that.