And Code Reusability Is Shot To Bloody Hell

[billroper]

So we're busily recoding all of our old MFC dialogs as C# dialogs in Windows Forms. Because of the particular architecture that was selected for the project, we can't use a mixed-mode assembly and link in all of the existing C++ classes that describe the data and all of the functions that we would normally use to contact our server application to retrieve information. Instead, we have to generate an XML request that is passed to a C++ COM object which does link with the existing C++ classes and which could, in theory, communicate directly with the server. However, instead the COM object then has an opportunity to massage (or not) the XML request which is passed along to a Java web service which then calls into a different C++ executable which decodes the XML, converts it to binary C++ objects, and passes the request along to the server via RPC.

The server sends back a selection of binary C++ objects. These are then converted to XML and passed back through the Java web service to the COM object, which may (or may not) then massage the XML before passing it back to the C# layer.

This is kind of sort of tolerable for a variety of architectural reasons, none of which I will go into here.

The problem is that we're not necessarily reading and writing consistent XML when we issue requests to the COM / Java / C++ / Server layers and when we convert the binary objects returned by the server into XML. For the most part (not all the time, but often enough to be annoying), each programmer who is working with a request that needs to be passed to the back-end server writes a brand-new XML command, even if we are already hitting the same back-end server call. This is because (again, for the most part) we don't have a common set of C# utility functions that would write the XML for us and submit it and because the C++ objects that we get from the server side don't know how to render themselves as XML.

And thus, we keep reinventing the wheel.

I just started seriously working on this project a few weeks ago and I have spent far too much of my time trying to write utility functions on the C# side and XML renderers on the C++ side. (And occasionally, a C++ constructor that accepts an XML description of the object so that I can create the object from the client-side XML.)

But it seems like the only sane way to do this.

Unless I'm seriously off base here.

Thoughts?

Comments

[fleetfootmike.livejournal.com]

Makes sense to me.
As does a visit to a few folks desk with a baseball bat and a copy of Larry Wall's three programmer virtues.

[phillip2637.livejournal.com]

Having (self-)limited Microsoft knowledge, much of the detail went by me but I can certainly testify to the value of making C++ objects that can append themselves to a XML stream when asked. I've done that a number of times.

[madfilkentist]

C++, C#, and Java all in the same project? That's scary. Having some kind of common language such as XML for them to pass objects around, and a consistent way to read and write them, does sound like the only reasonable way to go.

[mdlbear]

I'm sure there are good reasons for it, but it still sounds like too many moving parts.

I can, however, testify to the virtues of text-based formats like XML and JSON.

[kevinnickerson.livejournal.com]

I feel for you. I haven't decided if the current crop of programmers don't believe in code resuse, or just can't be bothered to either find if that wheel exists, or write a reusable wheel if it didn't.

[madfilkentist]

They believe in code reuse: Find it on Google and copy it. Some literally can't do anything more.