Saturday, March 26, 2005

JSP/Servlets compared to ASP.NET

I read up a little on JSP/Servlets + Rahul's post. They seem more similar to ASP.NET than plain ASP.

ASP was quite a mess really, because everything was on one page. You had a lot of "spagetti" code, no separtion of UI from code and it was interpreted, not compiled. It was recommended practice to create code, package it into COM components and then use these components from your ASP page. COM code was compiled so you got some performance inprovements. But it was a hassle and not very popular. The whole COM technology was messy - not dynamic with needing to reboot machines, registering/unregistering components etc...

Compared to Servlets, ASP tech was a joke. ASP.NET completely changed this, brought it on par and even surpassed it. With ASP.NET you get complete separation of UI and code. Basically, you get the MVC pattern for free (no need for external frameworks like Struts). You can integrate code within the same page as UI if you want, but it was kept for compatibility with ASP. To be able to "upgrade" old ASP pages to .NET. It is not recommended. VS.NET only supports "CodeBehind" wherein you have one page with UI and another code behind that page that is your logic. When you access an ASP.NET page it automatically combines these two pages into one "Page" class... similar to when you access a JSP page, it gets compiled into a Servlet.

I see that there is something new coming up called Java Server Faces. This is in direct reaction to ASP.NET server controls. Again their main motivation is to clearly separate code from presentation. Think about when you want to spit out a table with info from a database. You have to connect to the database, get a recordset, start a table, create a row, add first row of data, repeat, end table and then send it to the browser. Your presentation (the table) is intertwined with your code (connect to database, loop through records etc...). Server Controls in ASP.NET changed this. You just drop a DataGrid control in your page. In your "CodeBehind" page, connect to the database and bring back a DataSet. Then just bind this DataSet to the DataGrid. The DataGrid control will take care of outputting the table. Basically, you just pass it a collection of data and it takes care of handling the presentation. You can later set properties on it to change appearance etc... Everything about the DataGrid can be programatically accessed on the server side including a whole bunch of events. This is the essence of OOP. JSF seems to be doing something similar.

What I notice on the Java side is a plethora of different intimidating acronyms. JSP, Servlets, [Enterprise] Java Beans, Struts, Web Containers, Application Servers and now JSF. Obviously, Microsoft is known for integrating everything and Java is more community related with diff frameworks being "plugged" in (which is good in a way). I posted about this difference sometime back. But regardless, it seems like maybe the Java side tends to complicate matters a bit much? Maybe you don't need to use all these all the time? Maybe it's just for the super high end stuff - enterprise level? What dyou think?

No comments: