It happens all the time. A developer needs some functionality in their application so they start writing an interface and then an implementation to go with it. Then something doesn’t compile, the code doesn’t work right or they cannot figure out how to get their design to work. Next comes the inevitable question “How can I fix my interface?” The answer is “fix your interface by throwing it away.” To be fair it isn’t generally the developer’s fault they went this way. We are trained from an early (developer) age to write code like this. We hear about it in school. We go to our first job and they are using interfaces everywhere. The problem is it is the wrong approach. In this article I’m going to discuss why we (generally) have it backwards and how you can start doing things “the right way”.
Why Doesn’t This New C# Feature Compile?
It seems so simple. Someone posts an example of how to do something using a cool, new feature in C# and you try to use their code and it fails to compile. Or you see something documented as working and you try it and it fails to compile. Why is that? It actually is quite simple but probably not at all obvious to the average developer.
C# Iterator Oddity
If you’ve never used a C# iterator before then it may seem like magic. But under the hood it isn’t doing anything you can’t already do yourself. It is a time saver and as such there are quick actions and analyzers to recommend that you use them. If you’re like me you use them without even thinking but it is still important to remember they are generated code. It really shouldn’t be necessary to understand the underlying implementation of how they work but sometimes you have to. Here’s an interesting oddity that I saw recently with iterators.
HttpClient–Is It Really Thread-Safe?
HttpClient is the recommended way to make calls to web APIs in .NET. But it has some high startup costs. Microsoft recommends that the client be created once and reused throughout the life of a program. In modern applications we have multiple threads going at the same time so the question comes up “is it thread-safe”. The documentation says yes but having used it in multi-threaded code I was not so sure so I dug through the code to see if it really is. What I found is that it is – mostly.
Fluent Argument Validation
Quick, what is the syntax for ArgumentException? How about ArgumentOutOfRangeException? Did you know the arguments are swapped between the two? In one case the parameter name comes first while the other has the message first. Getting this wrong is so easy that it happens a lot.
Creating a Money Type
.NET does not have a type to represent monetary values. In general you will simply use
Decimal as it has the necessary accuracy. This has some limitations though:
- Without looking at surrounding code it is difficult to tell if a variable represents money or simply a large decimal value
- Currency information is not part of the type so it is possible to incorrectly mix monetary values in systems that support multiple currencies at once
- Displaying money requires that you use a format string to indicate the currency
There have been many implementations of money in .NET. This is my version. Please note that this code is new so bugs may exist. Additionally I’ve taken the requirements and implementation from my own needs. Your needs may differ so you may need to modify the code to behave differently for your applications.
Simplifying ADO.NET Data Access, Part 6
Time to finish up the series on simplifying data access using ADO.NET. We have simplified everything around ADO.NET except for actually retrieving the results. This is probably the most complicated part of ADO.NET given the need for cleaning up the reader, enumerating the results and reading the actual data. We can simplify all this logic down to a single line (plus any action to take for each row).
Simplifying ADO.NET Data Access, Part 5
This is a continuation of the series on simplifying data access using ADO.NET. We have a little cleanup to do around parameters before finishing up the series.
C# v6 Features–Nameof Operator
One of the cool new features coming in C# v6 is the nameof operator. This handy little operator solves a common code smell, string literals for programmatic items. Let’s take a simple example.
Simplifying ADO.NET Data Access, Part 4
This is a continuation of a series on simplifying the use of ADO.NET. In the last article we added the ability to cleanly separate query definition from the underlying data provider. But we left out parameters which are generally critical (and specific) to ADO.NET providers. In this article we will add support for parameters and add a fluent interface to make it easy to use.