Proxy Data Provider with WCF - Architecture

This article is a continuation of a longer tutorial. If you haven’t done so already you should read it from the beginning.

Architecture

I’ve structured the system according to the recommendations of Miguel Castro on Show #122 or dnrTV. I highly recommend you view this tutorial.

The full solution will consist of 4 required assemblies and two optional ones.

• Contract – Class library containing the IWcfDataProvider interface. This is the interface which serves as the ServiceContract for all communications between the service and data provider. By making it a separate assembly it can be shared on the client and server.
• Service – Class library containing the WcfDataProviderService class. This is the class which implements the IWcfDataProvider interface. This is the class that actually interacts with the database. This is where the bulk of the code will be written.
• ClientProxies – Class library containing the proxy class which connects to the service to send data back and forth. For this project we didn’t really need to make this a separate assembly. We could have incorporated it in to our DbProvider assembly. I chose to make it a separate assembly on the advice in the dnrTV episode referenced.
• DbProvider – Class library containing the classes which make up the data provider. Contains WcfDbConnection (IDbConnection), WcfDataReader (IDataReader) & WcfDbCommand (IDbCommand). This is the only assembly that needs to be referenced by the client application.
• ConsoleHost (Optional) – Command line program used to host the WCF Service. Used for testing and debugging. When deployed to production it would likely be preferable to use a different host such as IIS or a windows service for hosting.
• ProviderTest (Optional) – Windows application used to test data provider. This is a simple app that instantiates the data provider and populates a data grid.

Deviations from WCF Best Practices

One of the great benefits of WCF is the ability to build your services and consuming applications without worrying about the transport mechanism. This is normally left to be configured on the host and client applications via app.config (or web.config). This allows system administrators to make changes without rebuilding the application.

For most people this works out great. Unfortunately, it doesn’t work for a data provider. There are hundreds of programs that are designed to work with the generic IDb* interfaces and defer instantiation of the specific type of provider until run-time. For the WCF Data Provider to be usable by these applications, it must not require the client application to have any knowledge of WCF. All configuration must be set in the connection string.

This means all endpoint and binding configuration information must be passed in via the connection string. The data provider then needs to parse the connection string, retrieve the binding information and perform the binding via code. This will be discussed in more depth when I explain the DbProvider and ClientProxy assemblies.

Source Code

Previous: Introduction

Next: Contract

Comments

[Adamand Godson]

Please e-mail me your contacts!
______________________________
Blog