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.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.