Over recent years, I have become frustrated with the .NET teams using each release of their framework to advertise their latest features rather than ensuring their default templates adhere to good practices and design choices which are maintainable over the long term.
I know from first-hand experience that many organisations use these default templates as if they were canonically good practice, and never, ever change them.
I’ve reached the conclusion that the .NET team do not have the right incentives or interests to maintain good templates for the .NET community.
So, I’ve decided to create my own.
Better .NET Templates
Better .NET Templates can be installed from nuget by opening a command line and typing:
dotnet new install RichStokoe.BetterTemplates
This will install the template library.
Model-View-Controller (MVC) + Feature Slices
One key example where I believe the default templates set .NET customers up for failure is MVC.
The default template is designed around “Controllers”, “Models” and “Views” folders, rather than business domain concepts. This means that to show the index page, the controller is in one part of the project tree, and the view is miles away.
Software engineers generally consider high cohesion and low coupling to be signs of quality in a codebase so why doesn’t Microsoft honour this simple guideline in its default template for MVC? Instead, our projects reflect the technology choice rather than the business problem (a huge anti-pattern).
Years ago, one of the best advocates for good design practices, Jimmy Bogard, father of Mediatr, demonstrated his “vertical slice” patterns at a conference and this resonated with me as a very good way of combining the power of the MVC pattern without losing the business domain centricity.
The first template I’m shipping in Better .NET Templates is a new MVC template that allows you to use Feature folders instead of the big meaningless (in a business sense) Controllers, Models and Views buckets of the default .NET templates.
You can create a new project using this template like this at the command line:
dotnet new mvcfeatures
This will create a project like this:
Here we have a “Home” feature, under the Home directory is the Controller and any models that are needed, and the Views for that Controller. Everything in one place for each feature.
I get annoyed when templates don’t let me run the project immediately, so a lot of testing has been done to ensure you can just use
dotnet run and it will start your MVC project without fuss:
A few other benefits of using the
static void Mainas standard, removing “magic code” of top level statements and making diagnostics deterministic (“my application is failing in the Main method but there isn’t a Main method anywhere in the codebase??!?”)
- Separating out the setup of services (dependencies) and the request pipeline into
SetupServices.csto keep Program.cs simple.
Better JSON Defaults
Better Templates is opinionated about JSON formatting (but easy to change), see in SetupServices.cs:
- Camel case property naming by default
- No magic numbers for enums – uses the enum name (e.g.
- Removes null properties in JSON payloads (ensure your API documentation warns clients of this fact!)
Just the Beginning
This is just the beginning. The old adage is that you should feel slightly embarrassed about the first version you release otherwise you’ve released too late. It’s safe to say I’m slightly uncomfortable releasing it in its current basic state but I intend to iterate rapidly on these templates and hope other opinionated folks will contribute via PR at the following project: