Tales from the Evil Empire

Bertrand Le Roy's blog


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff


July 2004 - Posts

Some comments on Oracle's comparison of PHP and ASP.NET
Oracle recently published an outrageous article in a rather strange attempt to convince people that PHP is the best platform to write web applications. Not ASP.NET, which is not surprising coming from Oracle, but not Java either, which is a little more puzzling.
In this blog entry, I'm explaining what I thought when I read this paper. The disclaimer on the left applies, of course: these are my own opinions, and I'm not talking on behalf of my employer.
Are the UI layers disposable or should they be as easy to maintain as other layers?
The discussion began in french on the www.dotnetguru.org web site, but was unfortunately deleted by the administrator of the site because of a few aggressive comments.
I wish to continue this discussion here.
I'll post my own reflexions as soon as I have time to rewrite them or the DNG admin sends the deleted thread to me.
Please feel free to post your own and stay courteous. I'll delete all offensive comments, but only these.
Update 6/23/2004 19:00: Sami Jaber contributed to the debate through a blog entry. Thank you Sami (I would have liked to get my texts back, but I appreciate the effort). I'll try to answer his argumentation:
Sami explains that the UI layers are less stable because the lifetime of the technologies that support them are supposedly shorter than that of other layers. He cites:
- In the Java world, Servlets -> JSP -> Struts -> JSF, that is 4 (r)evolutions in about 6 years. Well, I won't argue on the instability of the Java world, but no one is forced to follow every new trend.
- POJO components (a relatively recently resurrected obvious concept: make it simple) implemented 6 years ago have remained stable, except if they followed the EJB specifications (two evolutions). Sure, an object is an object, and if it does not have any external dependancies, there's no reason why it would have to change. But this is of course an asymptotical goal...
- On Windows, we had MFC, then WinForms and Avalon. Sure, and what was the longevity of these technologies? Well, MFC is not dead, but between it (1992) and WinForms (2001), 9 years passed. Avalon is not due before 2006, that makes at least 5 years longevity for WinForms (assuming that every one will instantly migrate to Longhorn, which I'd like, but is not very likely). That makes technology lifetimes that can very well be compared with the lifetime of the technologies underlying other layers.
- Same thing goes for Microsoft Web technologies: ASP (around 1997 IIRC) lasted for about 4 years before being replaced by ASP.NET
- Sami argues that writing UI layers is very complex and that it is very difficult to achieve any kind of reusability. Well, I absolutely can't agree with that. First, I've been a web developer for years before being hired by Microsoft, and reusability of UI components is one of the things I've been the most successful at, through many advanced WebControls and the MagnitSite content management platform. WebControls are a major innovation that enables great reusability of UI elements, and Whidbey goes even farther in that direction, reducing the amount of boilerplate code to orchestrate the controls to almost nothing. Now, of course, you still have to write code for the specific interactions between your graphical components, but that is also the case for other layers. It doesn't mean that there is any reason why UI would be less manageable.
- A comment on Sami's blog points out that an IT person who would decide to migrate each application to each new trendy technology would be a fool. This is absolutely true, and the key is interoperability. I personnally have NEVER migrated a UI to a new technology. All my classic ASP sites remained classic ASP, and I developed only new applications using ASP.NET. Now, they were able to interoperate and this is what's really important. On the other hand, I've had numerous migrations of data layers to new versions or different databases.
Comments anyone?
Do data source controls belong on the page?
I get a lot of feedback on this subject (see this post if you have time for example). More and more developers are now finally getting the multi-layered application architecture concept, which is a great improvement over the situation we had even five years ago. So many of them, the first time the see data source controls on the page, go WTF is this doing in my UI layer? Even though the ObjectDataSource is here to make them feel better about it.
Well, first of all, in ASP.NET, the Page is not the UI layer exactly. It contains the UI (the Template View, that is, the CodeFront), but it also contains some form of controller or rather Page Controller (see Martin Fowler's Patterns of Enterprise Application Architecture). So it's actually more an application surface than a simple UI surface.
But it is also wrong to see the CodeFront as the UI and the CodeBehind (or CodeBeside) as the controller. You should see it more as the declarative part and the procedural part of the same object.
So what did we have in v1? To bind a control to data, you had to do it from the procedural part of the page. If you were doing it quick and dirty, you were instantiating a Connection, a Command or DataAdapter, and filling a DataSet or DataReader with it. Then, you would attach this DataSet or DataReader as the data source of your controls and call databind. If you were doing multi-layered development, you were instantiating objects and binding them to the controls in pretty much the same way. It should be noted at this point that if you wanted to prototype a quick-and-dirty page and then migrate this to a multi-layered page later, you had to rewrite a large part of this boilerplate code. The designer made all this a little more confusing by displaying some of the procedurally defined components on the designer surface despite the fact that they were nowhere to be seen in the CodeFront markup.
As framework developers, every time we see code that's copied all over any application with little variations, we have to ask ourselves if we couldn't make it declarative.
And that's what data source controls are: a declarative way to bind controls to data. Is anyone shocked by the presence of jsp:useBean tags in a JSP page? Well, you shouldn't be any more shocked by the presence of a data source control in an ASP.NET page. On the other hand, what's wrong is procedural code in the declarative part, and you should avoid this as much as possible (it is IMHO a great design flaw in JSP to define procedural markup).
By going from the procedural part to the declarative part, the data-binding code did not change layers, it just migrated to a different part of the same object.
The end result is improved productivity as you don't have to rewrite all this boilerplate code. You will also quickly notice that the migration from quick-and-dirty SqlDataSource to an ObjectDataSource is really easy as there is no source-specific code. All the visual controls see is a data source, they don't have to know where the data came from. All you have to really change is the data source itself.
But the data source controls have additional advantages. My favorite are parameters. You can add parameters to any data source. These parameters will allow you to declaratively filter the source's data according to a query string parameter, a form field, a control value or an arbitrary object value. Having a DropDownList filter the contents of a DataGrid has never been so easy: you can have such a page without writing a single line of code.
I'm currently writing a web site with Whidbey, and my goal is to have zero code in the web site project itself. It features declaratively interchangeable data stores and a fully skinnable UI. Having zero code in the web site is not a contrived exercise, it's actually promoting good design and the good news is that it's amazingly easy to do in ASP.NET v2.
So I'll say it loud and clear: ASP.NET 2.0 promotes good design.
VB.NET has "Using"! Hurray!
While looking for something completely different, I found this in the MSDN documentation for Whidbey. VB.NET now has Using, which was one of the many constructs that C# had and that were missing in VB.NET.
Let me remind you what using is. If you're using a resource that needs to be disposed of, like a connection, a stream reader or some weird unmanaged COM object, you typically have to write something like that:
Dim A as SomethingThatImplementsIDisposable
  A = new SomethingThatImplementsIDisposable
  ' Do something with A
  If not A is nothing Then
  End If
End Try
Well, to do the same thing in C#, you would do this:
using (SomethingThatImplementsIDisposable A = new SomethingThatImplementsIDisposable()) {
  // Do something with A
And now, in VB.NET 2005, you can do this, which is pretty much the same thing as in C#, except for the curly brackets:
Using A as new SomethingThatImplementsIDisposable
  'Do something with A
End Using
This is very important because contracting the habit to use Using whenever possible not only makes your code simpler, it also makes it less error prone. And unreleased resources are one of the toughest bugs to spot because the problem does not appear during development but a lot later, usually when the application goes into production (if you're careless enough not to do any stress testing before release...) or even much later. The resources actually get released, but during garbage collection.
As a rule of thumbs, when you see yourself writing A.Dispose(), you should ask yourself if you can replace it with a Using block, whether you develop in C# or VB.NET.
More Posts