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

Question

Hello,

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

This is a desktop application that "is not used over a network"... I'm failing to see a need for a real "backend" at all.

Write the desktop application in a single language, and store your data in XML.

Answer 2

What your friend is suggesting is to keep things modular. It doesn't really matter what language you use, but if throw it together in one big project you might make it non modular.

Answer 3

For that type of app I would use one only one language.

Answer 4

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 5

So your application is standalone and doesn't need to work over a network, but your friend insists on connecting the front and back ends of the app using sockets? Something is wrong with this setup, seems more complicated than it needs to be.

It sounds to me like your friend wants to use Java because he understands Java's XML handling framework better. Personally, I think interop between Java and .NET is overkill. You'll save yourself a lot of man hours and frustration by writing the app in a single language of your choice.

Answer 6

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.