Introduction to ASP.NET, ADO.NET – dead ringer for Oracle ADF?

After quite a few encounters with .NET in recent years, primarily up against Java/J2EE technology – and some with VB before the release of .NET in 2002 – yesterday I had my first real immersion in .NET technology. Our Knowledge Center (database) Server Development and Programming Languages had organized a session on .NET, to let a group of seasoned Oracle and Java/J2EE developers get a first glimpse of what all the buzz is about.

.NET architecture

Arjaan – one of our Java and .NET developers – gave us an overview of what the .NET framework is about, what the archiecture is and what underlying technologies are. Some of it was very familiar, other bits and pieces rather new. Also see: http://msdn.microsoft.com/netframework/technologyinfo/overview/.

The multi-tier model for .NET is of course very similar to the one we know for Java/J2EE. There is the Virtual Machine, CLR for .NET vs. JVM for Java. There is ADO.NET for database connectivity and data services. For HTML based Web Application Development, .NET developers use ASP.NET – very, very similar to JSP with JSF components. For GUI Forms development, there is .NET WindowsForms, very similar to for example Java Swing or Oracle Forms (Client/Server).

The use of WebServices turns out to be far less widespread in .NET than I had thought. There are many services (and a method is already a type of low level service) but not all that many WebServices. Entire .NET WebApplications can be compiled into a single DLL. Interaction between ASP.NET components and ADO.NET based data services are very direct and not at all through WebServices or even EJB like remote invocations. From a performance point of view this makes a lot of sense – the overhead with service invocation and untyped data with serialization/deserialization steps can be huge. It also means that typical .NET WindowsForms applications are not all that much different from for example Java Swing or Oracle Forms applications from an architectural perspective. And most Java/J2EE Web Application with their typical explicit MVC implementations are probably more open, more loosely coupled and better structured tier-wise – as well as often slightly less performant??

We concluded that the multi-language, single platform support in .NET – it has to be Windows platform but the set of potential programming languages includes C#, VB.NET and also C++, Cobol, Pascal, J#, Oberon, Python, JScript, Fortran, Perl, and many more somewhat obscure languages – as opposed to Java’s single language run anywhere theme, is somewhat hype-like. In theory, it sounds good to have so many languages at your disposal but in reality 95% or more of .NET development will use either C# or VB.NET – with no clear winner between these two. Being tied to the Windows platform for runtime deployment is a quite severe limitation that prevents adoption of .NET in some quarters.

ADO.NET, databases and data services

I had heard about ADO.NET but was not very well acquainted with it. Now I can position it against JDBC in combination with an Object Relation Mapping Framework. ADO.NET can communicate with most relational databases, through Database Drivers. Some of the drivers for popular databases are collected in the Microsoft Data Access Components (MDAC)product. Most database vendors not only have their own JDBC driver but nowadays also ship their own ADO.NET driver. Usually the vendor’s driver for a particular database is to be preferred over the Microsoft driver for that database. Microsoft prefers us all to use the SQL Server database with .NET applications, so it will not feel the zeal to produce the best possible driver for competing databases. By the way: the role the SQL Server database plays in the .NET framework does not seem to be any different from the role any other database plays. SQL Server is not necessarily any better for .NET applications, with the possible exception of the integration in the Visual Studio 2005 IDE.

The DataSet constructs in ADO.NET is very much like a ViewObject in Oracle’s ADF Business Components for example. The DataSet Reader looks very much like a read only ViewObject. There are many parallels to be drawn between ADO.NET and for example ADF Business Components. However, we did a workshop using (the free) Visual Web Developer 2005 Express Edition and it was my impression that ADF Business Components and its wizards and generators are more database savvy than the comparable tools in Visal Web Developer 2005. For example I had to type full queries and column names rather than simply select columns and have the tool create joins and select statements.

Arjaan explained that it is considered good practice to not have the ASP.NET application access the DataSet directly – which would be a lot like including JDBC calls or even SQL statements in JSP which we tend to avoid. Instead, a .NET application should have a DAO like service object that decouples data operations from the underlying table definitions. On top of the DAOs, there could very well be a Business Service like object – Facade like – that provides more coarse grained services that may involve several DAOs and indirectly DataSets.

We did a workshop in which we created a DataSet on top of a table in a SQLServer Express database. On top of the DataSet, we created a DAO and on top of that also a Service Class. We made use of C# as it was portrayed as being close to Java, with which most of us are more familiar. To say it is close to Java is almost an understatement. We wrote code that could have been Java – apart from the using keyword that replaces the import we know in Java and the apparent convention of starting method names with a Capital (perhaps that was just this workshop though). It is very, very similar!

Developing a web application using ASP.NET

The workshop continued with building a simple Web (HTML) Application on top of the Data Service. Our page would use a DataGrid – a multi-record table with single-record update/delete functionality as well as paging and sorting support. Very similar at first glance to the ADF DataTable on top of an ADF BC Data Control. And that similarity is not just superficial: it extends right to the property level and the IDE look and feel.

This was my first dive into the world of Visual Studio 2005 – that wonder of IDEs. To be frank, I was a bit disappointed. Do not get me wrong, it is a fine IDE. But it does not outrank IDEs like Eclipse (with a bunch of plugins) or JDeveloper (out of the box). In fact, I think from this brief first impression that JDeveloper 10.1.3 is a more powerful IDE, but that can be a matter of taste and personal experience. Visual Studio did not offer me features or tricks that were entirely new or quite surreal. A lot of drag and drop, a lot of property palettes and context sensitive popup menus. IntelliSense in XML and ASP documents – the same as the Code Completion I know from for example JDeveloper 10.1.3 in HTML, XML, JSP, JSF, UIX and even CSS files. Useful, but nothing new.

An ASP.NET page definition looks an awful lot like a JSP page, especially a JSP page with custom tags such has the ones used with JSF components. It is a bunch of HTML with specials tags that are interpreted at runtime. We can drag and drop components from Component Palettes. There are Data, Validation, HTML, etc. palettes that each present a different category of components. We dragged a Data Grid, connected it to a DataSource – at first a SQLDataSource, a direct reference to the DataSet we created earlier and later an ObjectDataSource that connect to the DataService wrapping the DAO wrapping the DataSet that we created later. Again very much like DataBinding in ADF, where we can base a DataTable on a DataControl’s iterator – in an even easier way. I was surprised to find a lot of the DataSource configuration stuff in the ASP.NET file. It is easy to find but not as easy to maintain and configure it would seem. Well, time and experience will tell.

Events like button and hyperlink clicking or data entry can very easily be linked to methods in a class behind the ASP page – like a Backing Bean in ADF JSF terms or the DataAction in ADF Struts/JSP. Adding validation or derivations in this way is very simple.

Interesting was the notion of MasterPages, a sort of built-in Tiles or SiteMesh functionality. Well, almost – as the reference to the MasterPage resides in the child pages rather than the other way round. MasterPages can be used to provide common page elements such as headers and footers and navigation bars, much like UIX templates did and somewhat more advanced than included JSP resources can do.

Conclusion

We managed to develop a simple web-application with a number of interesting features – database driven, data grid with sort, pagination and even filtering – rather quickly. Compared to traditional Java/J2EE Web Development – ORM, Struts and JSP based with poor IDE support – this is very productive. Compared with modern Java/J2EE Web Development, based on JSF, a data binding framework and done using modern IDEs like JDeveloper 10.1.3, it is still okay but nothing spectacular. I would expect us to be more productive using ADF Faces on top of ADF Binding and ADF Business Components than anyone doing Data Driven WebApp development using Visual Studio 2005, ASP.NET and ADO.NET, though the difference probably would not be very large and might depend on the particular components required for specific UI requirements.

It was very interesting to finally meet up with .NET. Some of the mystery is gone. Most of the aversion as well. The .NET framework and associated technologies are uncannily similar to their Java/J2EE counterparts. Both technologies evolve in productive mutual inspiration: no useful feature in either of the two stacks will be absent from the other stack for very long. A developer well versed in the combination Visual Studio, ADO.NET and ASP.NET can very quickly – some weeks or even days – be productive in a Java development stack such as Oracle ADF. And the reverse is true as well.

I expect we will get to .NET even better in the near future. To compete against it, integrate with it and even sometimes use it ourselves.