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?