“How should I design my ASP.NET MVC Project?”

You’re starting a greenfield ASP.NET MVC web site and you want to get it right so you start thinking about architecture. What folders should I have? where should my controllers go? Should I use AutoMapper and EntityFramework? Should I just pass my DataModels straight up to the view or map them to view models?

If you search the web for “good MVC project architecture” you will find plenty of advice (a lot of it contradictory) where you can happily while away the hours reviewing various options and opinions.

But when you’ve finished researching and designing the perfect architecture with it’s layers, repositories and Nuget packages, what are you left with? A project which does absolutely nothing useful whatsoever.

Zero features, zero value to your customer and an architecture you’re not sure is quite right but will do for now.

Why is this so complicated?

Don’t get me wrong, architecture does matter.

As your project grows, you will hit problems regarding maintainability, whether or not your application can scale. But if you get this far you’ve got a good problem to solve because it means your application is successful and is being used by real people.

If you get to this point it will be because you acted on feedback from your customer and delivered real value.

How I keep my focus

It’s hard to stay focused on building a feature because the technical questions come thick and fast. As soon you start writing code you face challenges; where to store the data, what ORM to use, what to call your controllers.

Fact: There is no single, comprehensive right way to structure your project.

It’s taken me years of failed ventures and frustration to realise it but pursuing the “perfect architecture” is a sure fire way to paralyse yourself through analysis and detract from time you could be spending on solving your customer’s needs.

So, when you start work on a new project, try these tips to stay focused on delivering value to your customers and getting early feedback.

1. Start with the user interface

It’s highly likely your users don’t care about the underlying technology your web application uses. What they almost certainly do care about is what it feels like to use.

They want to play with it, try it out for themselves and see what it can do.

Just as importantly, they want to see whether their grand visions for this software actually work in practice.

Whatever you think is the least UI you can get away with it’s probably too much. Find the smallest detail you can think of and implement it.

And when I say smallest, I really mean it. If it’s a heading, a textbox and a button, that might be enough. If it represents a tiny bit of functionality which the user didn’t have before, get it out there and invite feedback.

2. Don’t worry about styles

At this point you’re focusing on functionality. Can you get a prototype in front of the customer so they can try it out and give you feedback?

Whilst appearance and polish matters, it’s worthless if you end up throwing the feature away because it wasn’t what the customer wanted in the first place.

If you find yourself tempted to add just one more style, challenge yourself, is this page functional as-is? Can the customer try out their feature and get a sense for how it’s going to work? If so, get it out to them.

3. Hard code the data

Forget about databases for now.

Databases mean layers, abstractions and design. All of which are massive distractions from building your feature.

Instead, just keep the data in memory and serve it back to your UI.

Here’s an example using Web API.

public class OrderController : ApiController
{
    [HttpGet()]
    public List<Order> List()
    {
        return new List<Order> { new Order { OrderId = 1 } };
    }
}
    
public class Order
{
    public int OrderId { get; set; }
}

Even writing this simple code triggers a process in your mind. You’re already thinking, “hmmm, what do I actually need in an order”. This is a good sign, it means you’re focusing right in on the problem domain, the actual business problem you’re trying to solve.

So what do you need on an order? For a start, whatever your UI tells you.

Just as you focused on implementing the smallest piece of UI, only add fields to your objects that your UI needs in order to work.

Your next feature

Now is the time to try this for yourself. Whatever feature you’re about to work on, try these techniques and see if they help you stay focused on solving business problems.

Get feedback often and early and don’t be afraid to ask your customer for their input. I can’t remember a customer complaining that they were too involved in the process of building their software.

But don’t forget, as your application grows, architecture and clean software principles still matter, just don’t let them derail your project before it’s even started.