Wrapping 3rd Party Library

Aswerty

I have a question about an approach I've taken to implementing a 3rd party library in a .Net application I am building. The library is a comms library for a data server that stores primitive types such as bool, string, int, float, etc. It's a proprietory library and I didn't want to tightly bind it to the application so instead I've created a library that acts as a wrapper for it. My problem with this approach is that I seem to be duplicating a number of data objects, used to contain read/write/diagnostic data, which are already implemented in the library. The benefit I'm getting from this is that if I switch the comms library for another one this means I only need to make changes to the wrapper and not to the application itself. If I get rid of the wrapper this means a change in comms library would require making changes to the application code itself.

Currently I'm just doing synchronous communication but I'm particularly worried that the wrapper will become unwieldy if I start doing asynchronous communication. So for example a callback in the wrapper will then have to fire an event that triggers a callback in the application.

There is a reasonable chance the library will be changed at some point in the future but I don't know if this is reason enough to absract the comms library from the application considering the extra work and potential awkwardness of asynchronous communications it entails.

Anyways my question is do you think implementing the wrapper and inccuring the cost that goes with it is a good decision? And have you had similar experiences trying to loosely bind 3rd party functionality?

Procasinator

Is the Effort of writing a wrapper > The effort of re-writing to a new library?

How are you going about wrapping data objects? Could there be quicker way?

Aswerty

Oh sweet jesus, I 've lost two post in a row I've tried to submit!

I shall condense this to: one approach is quicker in the short term and the other in the long term.

Still divided on what way to go but will do some research on how I attempt to wrap the data objects and how I would propogate the asynchronous callbacks through the wrapper.

I get the feeling there is no best approach in this case, both have their advantages and disadvantages.

I think I'll keep going down the wrapper route for the moment unless something particularly awkward crops up.

Colonel Panic

You seem to recognise that having your code heavily coupled with this library is a bad thing. Can you minimise that aspect without having to fully wrap the library?

Perhaps you could write extension methods for the 3rd party data structures or your own or both that maps between the two of them without giving you too much of a headache should things change. Could you write an "ideal" interface that your own application would like to use, then make a concrete implementation that wraps the 3rd party library stuff?

Obviously so much depends on how you've done things, but normally, that's what I've done in the past.

Aswerty

Colonel Panic wrote: »

You seem to recognise that having your code heavily coupled with this library is a bad thing. Can you minimise that aspect without having to fully wrap the library?

That's what I've been doing so far. I only have the small part of the library that I use wrapped at the moment.

The library objects and the wrapper object conversion has been very manageable to date since I'm only mapping a small amount of data which I need. I proabably have a problem with it because it seems very reminiscent of the DAO/DTO pattern which I've always taken a disliking to.

Creating an ideal interface is something I've been thinking of doing. I might look at turning the wrapper into a comminication interface tailored to the application. So for example instead of having simple read and write functions I might have functions that check if certain thresholds have been passed or getting the mean of a number of values. In this way I transform the wrapper from just being an abstraction to being a layer that can provide business specific queries. This would be particularly useful since the server only provides basic reading and writing to specific records.

I think how I'd go about handling the async methods is my main issue now. I just know I'll be faffing around with Events, EventHandlers and Delegates which aren't exactly my strong point since I've mainly worked in web development.

kayos

Abstraction.... Yes it seems like a overhead now but if and when you do need to change the 3rd party component for another you'll be glad.

Aswerty wrote: »

I think how I'd go about handling the async methods is my main issue now. I just know I'll be faffing around with Events, EventHandlers and Delegates which aren't exactly my strong point since I've mainly worked in web development.

Well for async you have the EAP, APM and TAP patterns in .NET. I've used them all and TAP is the most straight forward if of course you are in .NET 4.5.

http://msdn.microsoft.com/en-us/library/jj152938.aspx outlines the 3 patterns.

TAP is handy as the basics are 2 keywords async , await and the generic Task class . Its about as easy as you can make async. It can also be used to wrap the 3rd party EAP way of doing async and exposing TAP to your application.

Aswerty

Thanks for the link Kayos. I hadn't actually been looking at any patterns for asynchronous implementations, I'd assumed the most straight formard approach would have been to implement the callback in the wrapper which fired an event that a handler in the application would detect and initiate the required logic. I guess this would have been an implementation of the EAP pattern although I wasn't aware that's what it was. I'm using .Net 4.0 and this seems to be the minimum version that supports TAP. I could've potentially moved to 4.5 since I'm in early stages of development but I'd have to contact one of our vendors to detemine if there was issues using 4.5 alongside their graphical controls library.

TAP is handy as the basics are 2 keywords async , await and the generic Task class . Its about as easy as you can make async. It can also be used to wrap the 3rd party EAP way of doing async and exposing TAP to your application.

Another potential advantage of the wrapper beyond allowing for loose coupling!