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 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.
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.
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.
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.
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.
An overview of XP Day 2011, held over 2 days in Central London. A thoroughly worthwhile conference run in the open spaces style over both days