We got most of the structural basics pinned down in Chapter 1. In this chapter, we’re going to look at building up the functionality of the app in order to make it do something more than just putting a message on the screen.
Specifically, we’re going to do the following:
Introduce a basic inversion-of-control (IoC) container. The idea here is that rather than explicitly creating view-model instances as we did in Chapter 1, we’ll ask an IoC container to pick one for us based on an interface that we provide.
We’ll build a set of classes that can call up to the service to
register the user. This will use the
HttpClient class available in WinRT to
actually issue the call. We’ll use the IoC container here, too, again to
create a loose coupling between the service proxy interfaces and their
The idea of inversion of control is that rather than having “direct control” over object creation—as we did in Chapter 1 when we created concrete view-models for our view-model interfaces—you have some code that is structured so that if you ask it to create an object of type X in order to provide some service it’ll choose the most appropriate concrete type for you. IoC “inverts control” by saying, “hey, give me an object that can do type X things, but I don’t care what you give me,” as opposed to direct control where you say, “give me an instance of object X.”
Implementation-wise, the basic idea of IoC is you ...