Quicker, Easier, More Seductive

At work we're planning to switch from Java to .Net, because we're switching our existing Java portal for a .Net portal (both proprietary, by the way). We've received books and a short time in the future the portal vendor will send someone out for a three-day training in portlet development. As time and duties allow, I've been skipping around in the books, researching various .Net resources and projects online, and trying out some code just to test my growing understanding. We don't have official development environments set up, so no Visual Studio .Net 2003 on my computer yet. 2005 appears to not be recommended by the vendor since the portal hasn't yet been ported to .Net 2.0. It seems to me that any modern tool should be able to target a particular platform version, but whatever.

I do have to say that, even without Visual Studio, the books and the code that I have experimented with give the impression that the ASP.Net framework has its act together. There are web controls, validation controls, the ability to make custom controls. Each control "knows" what it has to generate on the page and it exposes clear properties or attributes to make it fit into a given situation. And the programming model is all event-driven, with the server firing events from controls in a predictable manner. (Hmm, suddenly I don't think this resemblance to JSF is accidental...) C# is Java but without its warts. Then there's Boo, which I found just earlier today. Boo is Python for the .Net CLR but without its warts. .Net has a large number of third-party controls floating around to experiment with, in addition to Java doppelgangers NHiberate, NAnt, iBatis, etc. The .Net API has so much thrown in, and it makes data access and binding simple enough, that there may not be as much call for external libraries or frameworks.

I'm not convinced that this .Net approach of closely coupling code to page components is better for maintainability than a clean separation from View to Action (*cough* WebWork *cough*). Meaning, I'm not sure this .Net approach is more powerful, but I can say that even without Visual Studio it seems quicker, easier, and more seductive than the usual Java EE.