Program with C # interface and Java interface: good or bad practice?

My friend and I have disagreements about the problem of application development. This is a simple production management application.

According to my friend, the front-end stores data in XML and a Java program, will read an XML document, store it (in the background) and apply some business logic and again store the results in another XML document. And the C # interface will display the result (it wants to use sockets to pass the XML status).

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

Note The application is standalone. It is not used over the network.

Have you tried any of you? Share your thoughts :)

+3
source share
7 answers

You are right, and your friend made it poorly understood. In addition, from your question, I see that there are several problematic issues, I do not know where to start, so I just listed them, but not in any specific way. But the basic rule is for you to read: you have to accept that it’s easier than Einstein said: “Everything should be made as simple as possible, but not simpler” (or something like that, I don’t remember the exact quote).

  • The concept of front and back end does not really apply to a desktop application. Rather, you want to use the MVC pattern to separate problems. Wikipedia can be a good place to start exploring or browsing.
  • Why use a socket (which is completely unnecessary) if you do not need it. This is the first reason this is a bad idea, because you don’t need to use sockets if everything is done in a language that runs in the same process space (your application is a desktop or stand-alone application).
  • Similarly, why is XML (again unnecessary). Not necessary, because you can just pass Java or C # objects. With XML, the noise problem first occurs as tags are added to the true data. Then there is time for parsing, for building XML, additional libraries potentially, etc. Thid will be all the code that is introduced in your friendly approach.

These are the most obvious reasons. There are other reasons for the prospect of a manager or company:

  • To save this application, a manager or company must hire 2 different skill sets. This may not be true, as most programmers are multilingual. But this is not always the case.
  • As part of the deployment, you are now forcing your users to have both the JRE and the .NET framework, only to be able to run your application. And any of them is not quite small.
+10
source

Talk about making it difficult. Either Java or C #. This is actually not a backend for another. They both “do the same” as languages. The only difference is whether you want to use the power of .NET or the power of the huge Java infrastructures.

+5
source

This is a desktop application that is "not used over the network" ... I do not see the need for a real "backend" at all.

Write a desktop application in one language and save your data in XML.

+2
source

So, your application is standalone and does not need to work on a network, but does your friend insist on connecting the front and back ends of the application using sockets? Something is wrong with this setting, it seems more complicated than necessary .

It seems to me that your friend wants to use Java, because he better understands the XML processing infrastructure. Personally, I think the interaction between Java and .NET is redundant. You will save yourself a lot of man-hours and frustrations by writing an application in one language of your choice.

+2
source

What your friend offers is to remain modular. It doesn't matter what language you use, but if you throw it into one big project, you can make it non-modular.

+1
source

For this type of application, I would use only one language.

+1
source

Perhaps you can use the features of the C # desktop application in the interface and use Java Ejb + Web Service (Jax-ws) on the server. C # applications can read SOAP wsdl to create stubs and interfaces for accessing the Java backend implemented by Jax-ws.

+1
source

All Articles