Building websites with ASP.NET MVC. Want to learn more about developing websites using ASP.NET MVC? This blog is packed full of articles and tips to help you on your way.

Validation is an important part of form design. It provides guidance for our users. It informs the business rules surrounding the capture of data in our systems. Because it's a key part of form creation, we need to test it very carefully. A lot of the time, this testing is very manual. Can we speed things up?

In this article, we’ll look at ways to unit test our validation rules. We’re aiming to get fast feedback and a simple way of adding new edge cases. We’ll look at TestCase and TestCaseSource and how they can help.

Feedback is an important part of a good user experience. It is a normal, everyday part of using a website. Whenever we fill in a form, we expect to see some. Success messages. Error messages if we fill in the form wrong or we miss some stuff out. Most validation rules are simple. An empty field. An invalid email address. Not always, though. How do we deal with more complex scenarios? In this article, we'll look at a couple of approaches using Fluent Validation.

Do you do client-side or server-side validation? Well, client-side validation gives users faster feedback. The trouble is, you can only do client-side validation for straightforward scenarios. At some point, you'll need to check the state of your application's data. If you use Data Annotations, that means reverting to server-side validation. Adding validation logic to your controller actions. Wouldn’t it be better to have it all in one place?

In this article, we’ll compare Data Annotations with Fluent Validation. We’ll see how you can keep all your validation logic together. We’ll also use Autofac to hook the logic up to our controllers seamlessly.

Are you confused by Dependency Injection? SOLID principles? Inversion of Control? These concepts get thrown around a lot in our industry. That’s fine if you’re already an expert. But what if you’re not? What if you’ve got limited experience?

Maybe you’ve read about it in a couple of books. Got a grasp of the theory. That’s all well and good. But how does it translate to a real-world application? Why should you even bother with it if you haven’t used it before? You’ve been building websites for years and they work fine without it. What’s the big deal?

Don’t worry, you’re not alone. In this article, we’re going to try and cut through some of the buzzwords and jargon. We’ll aim to understand what role Dependency Injection plays and how it can benefit you. We’ll also look at using a Dependency Injection container (Autofac) and how it helps.

We’re overwhelmed with tutorials and guides about .Net development. There’s a plethora of how-to guides on every aspect of MVC. I’ve written plenty myself! Trouble is, we don’t just focus on a bit of it, if we’re building a website. We need to understand all those bits, for sure. More than that though, we need to understand how they all fit together. That’s the tricky part. There’s not as many articles around like that.

This is the first article in a series of end-to-end examples. In each one, we’ll take a business requirement and work it through from end-to-end. This week, we’re looking at unique username verification.

The web development space is awash with technology stacks and frameworks. There are now myriad techniques for building websites. Some work better than others. All have one thing in common, though. If you want to visit one, you have to request it from a web server. Sounds simple, right? Maybe if you’re a web development ninja and you’ve been doing this for decades.

But what if you’re not? What if you’re a desktop developer who’s just dabbled with web stuff? Maybe you are a web developer but you just haven’t got this far yet. Visual Studio has a web server built in, after all. You can build a website on your machine and run it. Website appears, happy days. Trouble is, you can’t host a production website using Visual Studio. Better use IIS then. How does it work though?

Making a web form read-only. Sounds simple, right? Well, there are a couple of ways we could approach it. We could use JavaScript and update the disabled attribute on each text box. We could create 2 big chunks of HTML within the page. One if the form should be read-only, the other if not. Feels a bit messy though. Is there a cleaner way?

In this article, we'll see how to use display and editor templates to achieve this task.

How can we avoid deploying flawed code to a production environment? We might be taking care of this if we’ve got a good CI process in place. If we use a tool like TeamCity or TFS. Running automated tests and code analysis. Insisting on code reviews before we commit changes. On a busy project it can be hard to keep track of everything.

In this article we'll see how pull requests can alleviate this issue. We'll see how to use them as a deployment tool in the absence of a CI workflow.

Why is it that some people seem to just “get” the whole cloud publishing thing? While others are left floundering, wondering how to take advantage of all that great stuff? Are you one of those?

Maybe you’re just learning how to code. Or you’ve been in this game for a while but never needed to publish a website to the cloud yourself. You’ve heard of Git - that’s a distributed source control system, isn’t it? Never used it though. How would you connect it to Azure anyway?

The art of building and launching a successful website has many facets to it. The build side itself is fraught with difficulty. Clients change their minds. Things turn out to be more complex than you first thought. Or (perish the thought), someone's been a tad too optimistic and things have overrun. Still, you soldier on, all pull together and make it over the line. Your website is ready to demo! Trouble is, it’s all on your local machine. You can see it fine, but what about other people? The world should be able to see your magnificent creation!

Help is at hand. In this article we'll examine a simple method to publish your website from Visual Studio straight to the cloud. We'll host it for free using Microsoft Azure.

Data comes in all shapes and sizes. We use it to describe attributes of all sorts of things. There are loads of web based systems out there for managing that data. Within them, we often need to look at different sets of data at the same time. Manipulate and analyse them in isolation from each other. DataTables provides a powerful way to do that. It has a lot of options though. There's a fair bit of repetition. Copying and pasting that plugin code everywhere. Can we create it once, pass a few options in, and generate it on the fly? Of course we can. In this article, we'll bundle up the table creation and plugin code into handy MVC helpers.

The internet is awash with data. So much so, it's hard to make sense of it all. Data about customers. Financial data. Data about stuff. Data that we need to keep track of and change. Most of the time we store it in databases. Sometimes we get hold of it through APIs. On occasion we present to people for analysis. One thing's for certain though. Howsoever we store it, we need to avoid information overload if we're viewing it on a website.

How do we avoid information overload? By viewing our data in bite-sized chunks. By allowing us to control how much we see and in which order we see it. DataTables gives us a powerful window onto our data. In this article we'll switch on paging, sorting and searching, and really get to grips with our data.

In part 1 of this series we were looking at connecting DataTables with Web API via a simple GET request. That’s fine for a small table. But what happens if our table has lots of columns? What if we’re not comfortable sending the data back and forth via GET? What if we're concerned about people snooping on our data as we send it back and forth? We use POST of course...

We’re all familiar with forms authentication these days. It’s one of the primary methods of limiting unauthorised access to your website. You know the drill. The user sticks their username and password into a form. The server verifies the details and issues a cookie.

But what happens if we throw Web API into the mix? What do we do if we need to restrict access to a Web API layer?

APIs are everywhere these days. We access the web now on a plethora of devices, from laptops to smart watches. More often than not they’re a key part of our architecture. What makes them so important? The data. Whether we’re building a mobile app or a thin web client, data is key.

Just as important as the data our API does accept is the data it doesn’t accept. The invalid data. The required field we don’t pass across. The password we set to the wrong length. Any API in the wild needs to validate the data we pass in. In the .Net world we capture those errors using ModelState. Trouble is, ModelState in MVC is a bit different from WebAPI. How can we make them talk to each other?

In this interconnected world, you have to deal with APIs all the time. A lot of the time you’re just querying them. Retrieving data. Sometimes you’re calling a public API. Most of the time you’re calling your own, internal API. If you’re calling your own API, it’s likely that you’ll need to post to it at some point, too.

Perhaps you need to send images or documents to it. Or maybe it’s good old fashioned form data. Fire it across via AJAX, job done? That makes sense for an image or a document. But what about sending form data? Chances are your form data’s a bit different from the API data. Better handle that in C# then. But how?

Ever had to call an API from your MVC app? A lot of the time you can use JavaScript. But there are times when the client-side approach just doesn't cut it. Maybe your app needs to use the API as if it were a database, or you’re calling a public API.

Chances are you need to transform the data somehow before it gets anywhere near the browser. Looks like you’ll have to call the API from your C# code. Sounds simple enough, right? Trouble is, you can’t seem to find any examples showing how to do this. You know how to do it using jQuery via a simple AJAX call. Can you do it in C# though?

In previous posts I've covered different ways of creating and populating view models. Thus far I've only focused on presenting data from the server within a view. But what if I were posting a populated model back to the controller? Well, I could use a view model for that too. The nice thing about MVC is that I don't have to.

The default model binder will bind to any type with matching properties. This means that we can create a clear separation around the direction the data travels. We can differentiate between data we display in the view and data we pass back to the server. In this post I'll discuss an alternative approach to passing data back to the server. The Command Pattern.

In an earlier article I wrote about reducing Controller dependencies with generic factories. One criticism of this approach, which I agree with, is that it hides those dependencies. It uses service location, a well-known anti-pattern. I had reasoned that some service location was acceptable in this instance. I wasn't injecting the container around everywhere.

I was using the container in one place, to resolve the specific factories that I needed. This was to avoid injecting many generic factories into a single controller. Instead I would inject in a non-generic factory. I would then use the service locator pattern to call the correct factory. I've thought about this a bit more since. A better approach would be to group the factories together somehow. In this article I’d like to discuss my approach to doing that. The façade pattern.

Make no mistake (no pun intended), becoming an expert in writing unit tests is hard. There are many approaches we can take and some work better than others. There are quite a few pitfalls too. I've created this guide to highlight some of the major ones I've noticed during my career. I've made many of these mistakes before. No doubt I'll make some of them again. I'd like to think I'll spot these issues earlier now, thanks to this guide. Time will tell.
by SimonRead more »

In my previous article I outlined a way to unit test HttpContext.Current. This was in code outside of a Controller. But what happens if we’re within a Controller? Inside a Controller HttpContext is abstract because it is of type HttpContextBase. This means we can mock it. But how do we achieve that?

How do we hook into those internal Controller properties? We need to inject a mocked HttpContextBase into our Controller somehow. We can do this by overriding the ControllerContext. In this post I’ll share the NUnit template I use for testing Controllers. I'll show you how to create a fake HttpContext. I'll also detail how to mock out the dependencies using NSubstitute.

How well do you test your code? Maybe you're a TDD ninja. Perhaps you're just trying to develop the habit of unit testing. You're trying to break away from mocking up an HTML page just for testing. Trouble is, you've fallen at the first hurdle.

You're writing a test against code that calls HttpContext. Well, HttpContext.Current to be exact. And the test fails. How frustrating is that? It's not even your code! In this post I'll walk you through a simple technique to make HttpContext.Current testable.

One common scenario presents itself over and over when developing MVC websites. How do we provide information to our users when they post data back to our server? Often, our users will fill in a form and post it back to the server. They now need a visual response to let them know that the operation was successful. In this post I’ll be exploring the idea of adding messages to TempData. We’ll display the messages in our view via an Html helper.

Display templates (along with Editor templates) are a powerful feature of ASP.NET MVC. They allow us to create reusable HTML snippets, much like we do with partial views. In this post we'll discuss how display templates can simplify our view logic. We'll display a collection of data without a single foreach loop in sight.

For those of us new to Dependency Injection, a common question to ask is: "How many dependencies is too many?" Coupled with, and soon following this question, comes: "How can I reduce this number?" With Controllers, we tend to focus on dependencies that pass data to and fro. We first take in, or "inject", interfaces into our Controller. We can then call the methods we need within our Controller logic. In this post I’ll discuss the use of generic factories for reducing Controller dependencies.

Making the jump from WebForms to ASP.NET MVC presents many challenges. One of the more difficult concepts to grasp is knowing what you should put where. You understand that a View is equal to a Page. You’ve got your head around the fact that a View needs a Controller Action to create it. You get that routing comes into play to match URLs to your Controller Actions. So far so good.

You’re even warming to the idea of using ViewModels to pass data to your Views. Question is, how should you populate your ViewModel with data? In this article I’ll be discussing the idea of using factories to create our ViewModels.

Imagine the scenario in which you have a bunch of items that need displaying in a view. Each item has an action button of some kind. We need to grab the id associated with that item so we can pass it back to the server. One approach to this problem is to handle the form submission with jQuery. In this article I’ll explain how we can solve this with jQuery data attributes.

Have you ever looked at sites that have real-time filtering of a grid or list of products and wondered "how can I do that?" Maybe you're developing a few intranet apps that would do well having this type of functionality. Perhaps you've looked around for good tutorials with examples so you can understand the process but you’re not even sure where to start?

We recently encountered the dreaded 'Not running in a hosted service or the Development Fabric' yellow screen of death whilst developing a client website hosted inside Azure. This post outlines one approach to accessing Blob/Table/Queue Storage services from an Azure Web Site.

Anyone who is familiar with TFS will have noted the apparent lack of filtering available when you view the history of a project within Source Control Explorer. This filtering and searching capability is available, but is hidden away inside a separate install, Team Foundation Power Tools.

I often get developers who are unfamiliar with the branching and merging process within TFS asking me how it works, so I've put together a short guide that explains the basics. This won't be applicable in all situations and covers the basic scenario of creating a single branch from Main and then merging that branch back in at a later date. This article assumes that you know your way around the TFS and Visual Studio environments.

I've put this article together to highlight some of the things you need to think about if you're thinking of taking the rather large step into the land of opportunity that is freelancing. There are a myriad of issues to think through if you decide to go down that route, but the rewards are worth the effort. Hopefully this article will provide you with some clarification to help make your decision about whether to freelance a little easier.