The Series

WCF by example is a series of articles that describe how to design and develop a WPF client using WCF for communication and NHibernate for persistence purposes.
The series introduction
describes the scope of the articles, and discusses the architect solution at a high level.

Chapter Overview

In the previous chapter, we introduced a basic WPF client. Currently, the View and the Model are almost ready, but the ViewModel does not provide any mechanism for
calling service methods. We previously discussed the need for decoupling the client from the WCF distribution layer. The goal is to provide a development environment
for RAD that leverages business exploration without the overhead of deploying a full production infrastructure. We would like to provide a development environment
where changes are inexpensive and deployments are easy. We don't want to install services in IIS, or maintain a SQL Server database; we are looking for an installation
that comprises a bunch of files that can be deployed in a memory stick if needed. BAs, product owners, testers should be able to execute this application in an easy manner.

Therefore, we need to abstract the distribution layer so different implementations can be used in a transparent manner. In this chapter, we will describe the contract
locator and how the client uses this mechanism to put in place a sort of pipeline pattern that provides the required functionality we are looking for.

The original implementation, although it resolved the coupling issue between the client and services, it imposed the overhead of maintaining a set of client classes
for each service implementation. A ServiceAdapter based on generic classes with generic functions and anonymous methods provide a much better implementation where
the client does not need to implement any additional classes to decouple the service calls. We also introduce in this article the CommandDispatcher which is required
at a later stage when WCF services are introduced on the client side, see Chapter WCF by Example - Chapter XII - WCF Implementation for more details.

Remove it from the ClientServiceLocator -- A ref to ICommandDispatcher is required

Remove ClientContractLocator

Remove IContractLocator

Remove CustomerServiceAdapter in the WPF project

Remove the ServiceAdapterBase class in the WPF project

Add eDirectory.Common.Message, ICommandDispatcher

Add CommandDispatcher to ClientServiceLocator

Create Server DirectCommandDispatcher class

Create generic ServiceAdapter class -- this version does not include the async internal dispatcher

Refactor tests

Command Dispatcher

The ICommandDispatcher interface provides a mechanism for clients to indicate which method and parameters are used when invoking a given service.
The only requirement for the client is to know the contract interface, it does not require to know about the implementation. On the other hand, the responsibility
of the ICommandDispatcher is to deal with the service implementation and pass the method results to the client. The interface is:

In this chapter, we will only discuss the DirectCommandDispather implementation that we use to connect the client directly to the service back-end without the need
of WCF and deploying the application on IIS. In this mode, the application just runs on a single application domain. This is useful for testing and RAD purposes.
The implementation is very simple:

The implementation is just a factory class (Line 01) that creates the service instance (Line 03) based on the TService that the client passes. If a new contract
is added in the server side, the only aspect to remember is to add the service to the map in line 02.

In Chapter XII - WCF Implementation, we will discuss the WCF implementation
of the CommandDispatcher. This is the production implementation and in a way simpler than the one we discussed above as it does not require any amendments when a contract
is added to the solution.

Client Service Locator

For some client services, a single instance for the whole life of the client application is sufficient and recommended. I normally like to create a sort of
service container where the code can easily fetch for this sort of resources without exposing the DI container. There are several ways to provide this
functionality and people have different opinions. In this case, we use the locator pattern in conjunction with DI
for dynamically resolving service implementations at run-time. For further information regarding DI, see Chapter X - Dependency Injection with Spring.Net.

The ClientServiceLocator implementation is straightforward; for the moment, we only expose the ICommandDispacher service but when we get
to the end of the series, this locator will expose two other services.

Service Adapter

The ServiceAdapter is being used by the ViewModels when they want to invoke service methods. This a generic class so the ViewModel when creating an instance also
determines which service contract the ServiceAdapter will deal with, for example:

In line 01, a new instance is created for the ServiceAdapter passing the ICustomerService contract interface. This mechanism will help to invoke the service
method in line 02. To execute the method, we just use the Execute method, this requires us to pass a function expression that takes an instance
of the service (this is the responsibility of the CommandDispatcher) and executes one of its methods. The return value, always an instance from
IDtoResponseEnvelop, is the result of the service method.

The way we have structured the ServiceAdapter and CommandDispatcher provides the developer a strong type mechanism for the ViewModels to invoke methods and
pass input parameters. It is similar to the RepositoryLocator that we will see at a later stage within the series but the generic ServiceAdapter provides
the additional functionality to deal with different service contracts. It is worth noting that the ServiceAdapter does not require a service implementation, and it is not
its responsibility to create/maintain a service instance, the CommandDispatcher looks after this aspect. The main reason for
this class is to manage the business warnings/messages in a generic manner. The implementation is as follows:

In line 01, we use the new ClientServiceLocator to fetch for the CommandDispatcher,
then in line 02, the command is passed to the dispatcher; see how the ServiceAdapter does not have a clue which service implementation is being used.

Test Re-Factor

We already have a set of tests that execute our services from the server side. These tests have been re-factored to use the ServiceAdapter instead. In this manner,
we can test the new infrastructure. I leave for the reader to inspect the code and see how these tests were implemented, they provide a comprehensive set of examples
on how to call the ServiceAdapter.

Chapter Summary

In this charter, we have set up the baseline for our distribution layer in the client side. Our design provides the decoupling required between the ViewModel classes
and the services that we mentioned at the start of the chapter. With a little change in our service tests, we have also demonstrated how easy it is to have the client
invoke the services in the server side. This model is critical to provide a plug-gable architecture so we can deploy our application during business exploration without
having to use WCF for leveraging the deployment process at this stage.

We have not discussed the WCF implementation; this aspect is covered in a later chapter in the series. However, as we will see, the WCF implementation is relatively straightforward
once we have in place the pattern introduced in this chapter. See Chapter XII - WCF Implementation.

In the next chapter, we will see how commands
are implemented in the front-end and how the ViewModel classes invoke the services using the ServiceAdapter
mentioned in this chapter. We are very close to having a comprehensive infrastructure in both the client and server side to start deploying versions of our solution to our client.

You can use this pattern but you may find that you need a new implementation of the ICommandDispatcher that allows async execution of the WCF methods but within a single call to the ExecuteCommand method.