C#/Java blend?
-
I just joined a group that has an existing codebase entirely in C#. It's not bad, but the code could be much improved (separating front end from business logic, isolating data access, ...). Personally, I'm a bigger fan of Java than I am of C# - force of habit. But beyond my personal preference, I can see this system benefiting from distribution, some standard persistence model, and true platform independence. I imagine there are solutions available in C# for these, but I know and am happy with the mature Java solutions for these issues.
However, the group is definitely into using Microsoft solutions, and I'll readily admit that I've never seen front ends in the miscellaneous Java technologies that could compete with the drag-and-drop interfaces you can build with Visual Studio. So I've been thinking, why not interface the two technologies - a C# front end communicating via Web Services with a Java backend. After all, it's pretty well acknowledged that though Microsoft is winning the desktop battle (including pretty, responsive interfaces), Java still has a slight advantage in the enterprise/server environment. Is this a complete WTF or might there be some value to this blended architecture?
Thanks.
-
@bernso said:
However, the group is definitely into using Microsoft solutions, and I'll readily admit that I've never seen front ends in the miscellaneous Java technologies that could compete with the drag-and-drop interfaces you can build with Visual Studio. So I've been thinking, why not interface the two technologies - a C# front end communicating via Web Services with a Java backend. After all, it's pretty well acknowledged that though Microsoft is winning the desktop battle (including pretty, responsive interfaces), Java still has a slight advantage in the enterprise/server environment. Is this a complete WTF or might there be some value to this blended architecture?
A hetergenous enviornment is a more expensive enviornemnt to maintain. Now you need N sets of experts instead of just one. So there had better be a pretty good reason for doing it ... a slight advantage just isn't enough to make it worth it, especially at the cost of using web services.
However, there are some perfectly valid reasons for eating the maintence costs and saving upfront:
1) Lots of skilled java veterans.
2) Invested in lots of UNIX/LINUX hardware
3) Vendor dependency
4) Lgacy code requring porting
-
@bernso said:
However, the group is definitely into using
Microsoft solutions, and I'll readily admit that I've never seen front
ends in the miscellaneous Java technologies that could compete with the
drag-and-drop interfaces you can build with Visual Studio. So
I've been thinking, why not interface the two technologies - a C# front
end communicating via Web Services with a Java backend. After
all, it's pretty well acknowledged that though Microsoft is winning the
desktop battle (including pretty, responsive interfaces), Java
still has a slight advantage in the enterprise/server environment.
Is this a complete WTF or might there be some value to this
blended architecture?
It's perfectly possible to do that, and it will probably even help you
to seperate the tiers and avoid vendor specific shortcuts that
compromise the quality of the design, portabilty etc.
Of course this should only be done if you have a group of developers
for the front end and another group of developers for the back end. If
you force people to work in C# and Java at the same time, the little
differences between those two languages will drive them mad; at least
you can say goodbye to coding style standards.
One last thought: Microsoft has a terrible (yes terrible) record for
maintaining the portability of their proprietary programming languages.
Back in '98, they introduced VB6 proposed to write business logic in VB6 and place it
in the MS Transaction Server. Only 5 years later, VB6 was legacy and while it's still
possible to use it today, there will never be a 64 bit compiler for
x86-64 Windows. Face it: it will be dead sooner or later. Moving it to VB.net is not as straight-forward as it should be.
Five years (or ten years, for the matter) is a ridiculously short
lifespan for business logic. It's perfectly okay to replace the front
end every (say) 5-10 years; adapt it to new operating systems, make it
more user friendly, utilitzing the growing power of PCs. But for any
reasonably large system, you don't want to do that with the business
logic. For that reason, I would prefer any other vendor than MS for the
language used for the business logic. Once MS manages to keep a usable
language upward-compatible and maintained for 15 years, I might
reconsider my position. Let's wait for 2018 to see if C# is a good idea
for business logic or not.
