Page 28 - MSDN Magazine, June 2019

PATTERNS AND PRACTICES
Super-DRY Development
for ASP.NET Core
Thomas Hansen
DRY is one of those really important software architecture acronyms. It means “Don’t Repeat Yourself ” and articulates a critical principle to anyone who’s maintained a legacy source code project. That is, if you repeat yourself in code, you’ll find that every bug fix and feature update will have you repeating your modifications.
Code repetition reduces your project’s maintainability, and makes it more difficult to apply changes. And the more repetition you have, the more spaghetti code you’ll end up with. If, on the other hand, you avoid repetition, you can end up with a project that’s signifi- cantly easier to maintain and bug fix, and you’ll be a happier and more productive software developer, to boot. In short, committing to DRY code can help you create great code.
Once you start thinking in a DRY manner, you can bring this im- portant architectural principle to a new level, where it feels as if your project is magically rising up from the ground—literally without hav- ing to apply any effort to create functionality. To the uninitiated, it may
seem as if code is appearing out of thin air through the mechanisms of “super-DRY.” Great code is almost always tiny, but brilliant code is even tinier.
In this article, I’ll introduce you to the magic of super-DRY development and some of the tricks I’ve used over the years that can help you create your ASP.NET Core Web APIs with much less effort. Everything in this article is based on generalized solutions and the concept of DRY code, and uses only best practices from our indus- try. But first, some background theory.
CRUD, HTTP REST and SQL
Create, Read, Update and Delete (CRUD) is the foundational behavior of most data models. In most cases, your data entity types need these four operations, and in fact both HTTP and SQL are arguably built around them. HTTP POST is for creating items, HTTP GET is for reading items, HTTP PUT is for updating your items, and HTTP DELETE is for deleting items. SQL likewise evolves around CRUD with insert, select, update and delete. Once you give it some thought, it’s pretty obvious that it’s basically all about CRUD, assum- ing you don’t want to go “all in” and implement a CQRS architecture.
So you have the language mechanisms necessary to talk about HTTP verbs in a manner that they propagate all the way from the client’s HTTP layer, through your C# code, and into your relational database. Now, all you need is a generic way to implement these ideas through your layers. And you want to do it without repeating yourself, with a brilliant architectural foundation. So let’s get started.
This article discusses:
• Using dependency injection to improve encapsulation
• Employing ORM to abstract away from a database
• Achieving full modularization of code by avoiding direct references between modules
Technologies discussed:
ASP.NET Web APIs, HTTP REST, Generics, Polymorphism
24 msdn magazine