.NET 2.0 Changes, Impacts. J2EE Problems vs .NET problems


EJB design: .NET 2.0 Changes, Impacts. J2EE Problems vs .NET problems

  1. I have developed some applications using .NET and a few with Java.

    Now that we know the extent of the changes that will happen to .NET (in ver 2.0) I wanted to have an idea of what people think about developing with .NET? Winforms and Webforms will change so thes will not have a great impact on older .NET projects?

    On the other side Java programmers do not seem very satisfied with EJBs (which seem to be one of the key technologies in J2EE).

    I am working in enterprise level (Banking industry) but I have my own software business so I need to have a good view of the problems and positive points of both.

    I will really appereciate your opinions and help.

  2. Hi,
    I don't know much about .Net but I do have some experience on J2EE
    The first thing is J2EE != EJB, surely EJB is a big and important part of J2EE, but not all (actually rare) application really need EJB. These projects can live without EJB and use some others presistent framework / technology

    I love J2EE because of:
    --session bean and message bean
    --application can cluster and scale up pretty easy if you implement and design it well
    --excellent, useful Java core API
    --plenty of open source product VS if you use .Net, you need to stick with Micorsoft

    btw, if your app. is a banking system, I don't think any O/R, presistent framework can suit your requirement.

    However the declarative, distributed transaction management on all major J2EE app. servers will surely be the most important feature that you should concern about banking on J2EE.

    I think most people don't like EJB mainly because it's speed, and most application can't build without some direct JDBC code.

  3. Koon, really thank you for your comments. So if we do not like the speed of Entity EJBs we may use another persistence library without problem while we are using other types of EJBs yet?

    Also yes, most important feature in banking systems is distributed transaction management and some people have used other means like BEA's Taxedo for this.

    I will appereciate if you can introduce alternative technologies for J2EE (alternatives to EJB and others) which have real benefits.

    Mac, ProgrammerNet.org
  4. For most of my career I’ve developed using Microsoft technologies and, for what its worth I’ve used .NET and J2EE both fairly heavily. Both are perfectly good platforms for developing enterprise applications, and both have their strengths and weakness, but in a clean situation where I get to make the decision I currently go for J2EE every time. The reasons for this are generally:
    1) The huge range of vendor and OS support. Choices from BEA, IBM, Sun, Macromedia, Jboss, etc. etc. etc.
    2) The relative maturity of the API’s and the breath of tools in the toolbox.
    3) The vast collection of great, mature web framework alternatives that are about (though some of these are being ported to .NET).
    4) The Exception handling model – I much prefer having checked exceptions to not having them. Also the .NET libraries still have endless examples of Exceptions where the error is “thrown away” during handling (a consequence of their relative lack of maturity and something which will, I’m sure, get addressed in time).
    5) The quality of the IDE’s. For my taste, IntelliJ IDEA is a long way ahead of Visual Studio .NET at this time. There are other good, free IDE’s (Eclipse, Netbeans etc).

    The performance of EJB-based J2EE systems overwhelmingly depends on their design. The design sensitivity is one of the main reasons why there are so many stores about badly performing EJB projects and is also a major reason why patterns are so popular in the J2EE space. It is true that you pay a price for a standardised API (as you always do), but on the other hand you get you get an API that has support from third-parties for development, testing, tuning, deploying, scaling, persisting, clustering and load-balancing. When EJB has been the thing I’ve needed, I’ve always found using it pays dividends. Moreover I’ve had big performance and scalability problems with .NET solutions as well as with Java ones.

    .NET probably has the edge (just) in terms of building Rich Client GUI though it is far from being perfect– and Java again benefits from the huge vendor support it has with IBM’s SWT (used on Eclipse) and QT bindings being developed. Moreover Swing has improved greatly in terms of performance and responsiveness with Hotpot (as IDEA demonstrates).