Decouple object tier from Windows Forms application

Question

The situation:

• My company delivers an installed Windows Forms application to our clients.
• This client application comes bundled with an object binary (let's call it Objects.dll)
• Objects.dll contains the object properties, fields, method signatures, etc.
• Objects.dll also contains the Service Contracts (interfaces), used by the object to communicate to a remote web service
• The remote web service (let's call it Service.dll) is hosted remotely, along with Objects.dll. It implements the Service Contracts in Objects.dll

The problem:

• When the Objects.dll changes in any way (including the Service Contracts), an update must be sent out to the client application. Updates like these require 48+ hour notice, and a pretty hefty middle of the night maintenance window. This is painful, and it goes against our internal development credo of having low-impact deployments.

The hope:

• There exists a tool/product/service that allows some level of decoupling of the object tier from the client application. I'm envisioning some service/object discovery service for the client application to communicate with in order to get the object tier.

It's possible that a solution doesn't necessarily exist. While that would be less than ideal, I'm fully anticipating this solution.

• Robert Harvey: When you say "updates like these," don't you have to change the client anyway, if the Service Contract changes? Or is your intention to push updates to the client without ever changing any classes?
• Tony Morris: @RobertHarvey - Yes. When I said "updates like these," I meant "updates that are pushed out to clients." This includes when the Objects.dll changes in any way, which includes Service Contracts changes. In my "perfect world" scenario, which may not be realistic, I would like to have the application "self-aware" of the implementation of the Objects.dll, so it doesn't need an application update, but can just update its internal implementation.
• Robert Harvey: How do you update the Winforms application?
• Tony Morris: @RoberHarvey - It checks against a homegrown update web service that, upon version increase at the web service layer, downloads the updated binaries in a separate process.
• Robert Harvey: And the Objects.DLL is not part of this feed?

Answer 1

You need another layer

When you see problems like these, it is an indication that your solution is missing a layer of abstraction. There ought to be something that has a fixed, public interface and a private implementation which isolates the caller from underlying changes. There are three places you can put it: where you add it can depend on project concerns such as who is going to do the work and whose budget will pay for it.

At the service end

Ideally, the folks developing the service would provide a layer of abstraction between the API and the business logic, e.g. an interface, which is generic enough to avoid frequent changes. If a data type or parameter name changes in the underlying infrastructure, the service would isolate the caller from those changes by mapping existing interface elements onto the new structures or delegates. A new interface should only be needed when there is significant change in functionality (in which case you'd need to revise the Windows application anyway).

At the client end

If they are not willing to do that, you can add an adapter layer on the client side which would have a fixed public interface and a private implementation that deals with the raw service APIs. You'd need this adapter to be distributed in the same package that contains updates to objects.dll. And ideally it would be built as part of the continuous integration build for objects.dll to ensure compatibility.

In the protocol

If you use a RESTful protocol, the client can dynamically discover any new interface elements using the Uniform Interface.

If you use a JSON sort of protocol, the server and client can support new interface elements via duck typing.

If you are using WCF, you can use lax versioning to alleviate the problem. Under this pattern, removal of existing interface elements will still break the solution, but you can add new elements without breaking it.

• RubberDuck: +1 for the lax WCF versioning. It really should be the default and I believe OP is using WCF, even though they didn't state it explicitly.