Program with C# front-end and Java back-end: Good or Bad Practice?

Question

My friend and I are having a disagreement over an application development issue. It's a simple production management application.

According to my friend, the front-end stores data in XML, and a Java program will read the XML document, store it (at the back-end), and apply some business logic and again store the results into another XML document. And a C# front-end will display the result ( He wants to use sockets for communicating the status of XML ).

I think this is a bad idea. I suggested that whole application should either be written in C# or in Java.

Note: The application is standalone. It's not used over a network.

Have any of you tried this? Please share your thoughts :)

Answer 1

Talk about making it complex. Either Java or C#. One really isn't a backend for another. They both 'do the same things' as languages. The only difference is whether you want to leverage the power of .NET, or the power of the immensely huge Java frameworks.

Answer 2

You're right and your friend gave a bad idea. In addition, from your question, I see there are several troubled issues, I don't know where to begin so I will just list them but not in any particular oder. But the ground rule for you to read on is you must agree that simpler is better as Einstein said "Things should be made as simple as possible but not simpler" (or something like that, I don't remember the exact quote).

1. The notion of front end and back end do not really apply to a desktop application. Rather, you want to use the MVC pattern for the separation of concerns. Wikipedia might be a good place to start learning or reviewing.
2. Why use of socket (which is totally unnecessary) if you don't have to. This is the first reason why it's a bad idea as you would not need using sockets if everything is done in language, running in the same process space (Your app is a desktop or standalone app).
3. Similarly, why XML (again unnecessary). No need because you can just pass Java or C# objects around. With XML, first there is the signal to noise issue as tags are added to the true data. Then there is the time to parse, to construct the XML, additional libraries potentially, etc. Thid would be all that code which are introduced in your friend's approach.

These are the most obvious reasons. There are other reasons from a manager's or company's perspective:

1. To maintain this application, the manager or company needs to hire 2 different skillsets. This might not be true as most programmers are multilingual anyway. But that's not always the case.
2. In term of deployment, now you force your users to have both the JRE and the .NET framework installed just to be able to run your application. And either of those is not exactly a small footprint.