I
feel like with the advent of Blazor, the power, usefulness,
and ubiquity of C# and .NET in general has kicked up a notch. At the
same time, the growth in functional programming (LINQ in C#, F#,
Clojure, Scala) and separately, dynamic typing (Javascript, Python), and
fluent APIs/DSLs all give us better ways of both thinking about and
writing our code--we can be more expressive and simpler while being less
error-prone. C# is becoming the best of all worlds as these paradigms
become nearly fully enabled in C# with the variety of NuGet libraries
enabled.
Here are some interesting NuGet packages that I haven't used yet, but might take advantage of soon.
- FluentValidation - On
my current work project, we just wrote a bunch of complicated (though
not complex) validation code, all custom, and mostly with nested if
statements. I wonder if this would be more readable and intuitive using
a library like this?
- Humanizer
- So much of our code is just variations on mapping identifiers,
timestamps, or logic into human-readable forms. This package provides a
ton of methods for doing this in a simpler and more intuitive way.
- FluentMigrator -
So far, I've never worked on a project that has successfully kept its
database schema in code, other than by retaining SQL scripts. Could
this library help?
- Polly -
Retries, timeouts, and more - I've often written custom methods to deal
with various service accessing needs. Next time I feel like I should,
I'll have a look at Polly.
- OneOf -
I see often where I need to return two different types--one for success
and one for an expected failure or "nothing to do" case. Functional
languages have handled this better than OO languages from the start, but
maybe this library could bring me the ability to return OneOf<bool, FailureMessage> or any other union that might be useful.
- Dynamic LINQ - Could it help or hurt to be able to dynamically build your LINQ logic depending on runtime state? I've often wanted to, but understood why C# can't do it by default. Could this package enable such power? Or would it do more harm than good?
These are of course in addition to the ones I've already used repeatedly--if you don't know them well, take a look for sure:
- Dapper - EF
is great but I still think it is overfkill for most needs, especially
if your team is proficient in writing SQL (and they should be). I
cannot bear the thought of spending an hour to make EF do what I want
when I could just write my own SQL and be done with it. Dapper does the
part I want (Mapping rows to objects) and leaves out the part I don't
(Mapping code to queries).
- FluentAssertions - It is so much better
to write intuitive assertions in my tests than to even take the 20
seconds to write it with traditional MSTest assertion syntax. Goodbye
Assert.IsTrue, hello result.Should.
- Moq - There seems to be nothing better for detouring/mocking in your automated tests. Even though .Setup and It.IsAny<T> get tiresome, I haven't found anything better.
- Swashbuckle with Swagger and SwaggerUI - This trio gives my API documentation with hardly any effort. Nice!
- Serilog - We finally have a winner in the logging library fight. Everyone loves it; you will too. Ditch Log4net, nLogger, or anything else you might have struggled with before.
