Peter Vogel returns to creating a Windows Communication Foundation (WCF) router that loosely couple services with their clients. But this time he uses XML to configure his router rather than doing it in code.
Implementing design patterns in the Microsoft .NET Framework isn't all that hard to do; understanding what each pattern does for you and picking which one to use is the real issue.
Workflows make it easy to do something that's very hard to do in any other development environment: Take action when something doesn't happen. Here's how to protect yourself when something's isn't happening in your Windows Workflows.
There's a well understood UI design process that you can use to get to the "right" UI for your application. And it starts by inventing people.
Creating connectable Web Parts is a good thing for you and your users -- and the default interfaces that come with SharePoint form the architecture you should use to create those Web Parts.
Peter returns to creating a provider WebPart, but this time passes SharePoint list data from one WebPart to another.
The IWebPartParameters interface provides a flexible way for one WebPart to select the data it wants from another WebPart. And, since implementing that interface doesn't require much code, you should consider using it on all your WebParts.
Because SharePoint lists are automatically turned into connectable Web Parts, you can integrate your own Web Parts with any existing SharePoint list by implementing the default interfaces provided by SharePoint.
Peter finishes up his discussion of using the Fakes Framework with TDD in Visual Studio 2012 Ultimate by looking at mocking properties and why you'd want to pass a shim as parameters.
Using shims in Visual Studio 2012 Ultimate lets you easily bypass code—no matter how deeply buried—to test just the parts of your application that you want to test.
One of the major reasons that developers don't like TDD is because, inevitably, it leads to mocking—which can be time consuming. Microsoft has created the Fakes Framework just to simplify the whole process.
The key decisions -- the "architectural" decisions -- in user interface design aren't technical ones. The good news? Just two principles that drive those decisions. The bad news? You won't like either of them.
The difference between Structs and Classes isn't about data vs. code: it's about what happens when you move the data around. And sometimes you want a Struct, not a Class.
Peter returns to the ASP.NET Web API in Visual Studio 2012 to use it with ASP.NET. And this time, he's moving complete objects from the client up to the server in an HTTP POST.