The Good, the Bad, and the Code: ASP.NET Starter Samples and Beyond

This article is written as part of the Accelerate App Development with GitHub Copilot Hackathon to reimagine how starter templates can be improved using software design patterns and Copilot.

You're a developer diving into the world of ASP.NET, and the starter samples are your lifeboat. They're great for getting you afloat, but when it's time to sail into the deep waters of enterprise applications, these samples often leave us wanting more. It's like starting a journey with a map that doesn't quite cover all the landmarks.

The Quest for Separation of Concerns

Enter the hero of our tale Separation of Concerns (SoC). Martin Fowler hit the nail on the head in his book "Patterns of Enterprise Application Architecture" when he wrote:

"The key to successful software design is understanding the different aspects of a problem and separating them into different parts of the system."[1]

Think of SoC as the magic that turns a jumbled puzzle into a clear picture. It’s about ensuring that each part of your application has a single job and interacts seamlessly with others.

The Data Access Layer: The Backbone

Let's kick off with the Data Access Layer (DAL). In the starter samples, you might find a simple approach that works for small projects. But for enterprise applications, you need a DAL that’s robust and modular. This layer should isolate data access logic from business logic, often using repositories or data mappers to keep things tidy and reusable.

A key consideration here is making your DAL platform agnostic. This means designing it so that it isn't tightly coupled to a specific ORM (Object-Relational Mapping) tool. Doing so gives you the flexibility to switch ORMs without significant rewrites. As Uval Lowry, Microsoft MVP and master software architect, points out:

"Reducing volatility in your system architecture can lead to more predictable and stable outcomes."[2]

In his article "Repository Pattern - A Controversy Explained" Steven Giesel discusses how a repository pattern can be effectively used in the Data Access Layer to abstract data access and decouple it from the business logic layer.[3]

Employing such patterns ensures that your application remains flexible and maintainable, regardless of how the data layer evolves. With that being said, not every solution requires a repository pattern as Steven Giesel points out there are benefits to using tightly coupled ORMs in your design if your data source doesn't change that often.

The API Layer: The Gatekeeper

Next up, is the API Layer. It’s like the front door to your application, handling client requests and responses. While the starter samples might give you a basic controller, an enterprise application needs more. Think scalability, maintainability, and perhaps even using patterns like Mediator or CQRS (Command Query Responsibility Segregation) to keep things organized.

Unit Testing: The Unsung Hero

And then we have the unsung hero of our story Unit Testing. It’s the safety net that catches bugs before they become nightmares. Yet, the starter samples often skimp on a comprehensive unit test project. Tools like xUnit or NUnit, paired with mocking frameworks like Moq, can make a difference in ensuring your app is rock-solid.

Infrastructure: The Deployer

Finally, let's not forget Infrastructure. At this day and age, can code exist without a way to deploy it? An enterprise-grade application needs a well-defined deployment strategy. This could involve using tools like Docker for containerization, Kubernetes for orchestration, and CI/CD pipelines for automated testing and deployment. Ensuring that your code transitions smoothly from development to production is crucial for the stability and scalability of your application.

A Better Structure Awaits

So, while the ASP.NET starter samples are a great beginning, building a high rise requires more detailed blueprints. Here’s a peek at what an enterprise application structure might look like:

GitHub Demo Link: Enhanced starter template

[1]: Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002.

[2]: Lowry, Uval. "Reducing Volatility in Your System Architecture." Microsoft MVP Blog, Microsoft

[3]: Giesel, Steven. "Repository Pattern - A Controversy Explained."