# Wednesday, August 29, 2007

Let me just say that I am pretty impressed by what Miguel De Icaza and the other Mono guys have accomplished by creating Mono.

I have never been impressed by Linux and I am not surprised by the slower than expected adoption of the operating system, despite huge efforts by Novell and Red Hat. To me, the main reason is the lack of standardization in the different distributions. Setting up and configuring a Linux system is never the same. Different vendors use different front-ends (Gnome vs KDE), the file systems are organized differently, boot procedures are totally different, ...

But, I have always been intrigued by Mono, the .NET platform for Linux which is "sponsored" by Novell. Mono has always been pretty up-to-date by implementing new .NET stuff and compiler features as soon as (or sometimes even sooner than) Microsoft made them publicly available

I was a little curious to see how ProMesh.NET (MVC Web Framework for .NET 2.0) would run on Mono (if at all), so I did the following:

  • Download the VMWare image with a pre-installed Mono installation on SUSE Linux 10.2
  • Download VMPlayer (free)
  • Copied the latest ProMesh.NET source tree to the virtual machine
  • Fired up MonoDevelop
  • Compiled the framework... Works (well, it compiled)
  • Copied the ProMesh.NET demo application to the virtual machine
  • Compiled the demo app... Works!
  • Started xsp2.exe (the lightweight .NET web server for Mono)
  • Opened the index.ashx page using FireFox: WORKS
  • Went through the complete demo site. Everything worked!

I was utterly amazed by the painless process of compiling and running a ProMesh.NET application on Mono, something I've never tried before (I did have some previous experience with MonoDevelop, but not a lot).

This is pretty exciting stuff, knowing you can just grab your ProMesh.NET web application, dump it on a Linux box and run it from a Linux web server.

Mono team: good job!!

kick it on DotNetKicks.com
Wednesday, August 29, 2007 9:20:10 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [2] -
 |  |  |  | 
# Wednesday, August 08, 2007

Scott Bellware wrote an interesting article “Monorail vs. Rails Isn't a Meaningful Question” which touches the subject of choosing a technology for building web applications.

The question “if you're building web apps on .NET, what leads you to assume that you should be building on .NET?” came up twice in his post. While this is a question a technologist might ask, it is a no-brainer for the stake-holders.

Think about this: As a stake-holder, why would you use Ruby (on Rails) when it is at least 100 times harder to find Ruby developers than it is to find good .NET developers? You wouldn’t. Even if I was a die-hard Ruby enthusiast, and I needed to build a “real” web application my company depended on, I would never pick Ruby on Rails.

So obviously .NET is a safe choice, but that doesn’t necessarily mean you should use the ASP.NET framework. There are other (better?) frameworks available for building web applications in .NET (I even doubt that the Microsoft website is using ASP.NET Web Forms for all its content). It’s not that hard to teach a .NET developer how to use MonoRail or ProMesh.NET or (…), but it is a lot harder to make a C# developer use Ruby (on Rails).

Ruby may be the better technology for web apps, .NET seems (for now) to be a better (business) choice for real web applications.

kick it on DotNetKicks.com
Wednesday, August 08, 2007 12:47:31 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [17] -
 |  |  | 
# Monday, August 06, 2007

One of the most powerful features in .NET is the ability to use reflection to do all kinds of neat stuff at runtime, like

  • Find out what properties, fields, methods, etc. are in a class
  • Create objects without knowing their type at compile time
  • Call methods by name (even private ones)
  • Check attributes on classes, methods, fields, …

The web framework I built over the last few years, ProMesh.NET, relies on reflection for a lot of the features it offers. Often though, I am asked if the heave use of reflection doesn’t have a significant impact on performance.

My answer usually is: YES, but it doesn’t matter. Now you probably think that I don’t care about performance or that I’ve had too much too drink. None of the above. I’ll explain:

In ProMesh.NET, there’s a feature that allows you to just declare session properties in your class that will be constructed at runtime, like this:

   private SessionProperty<string> _mySessionVar1;
or
   private SessionProperty<string> _mySessionVar2 = new SessionProperty<string>();

You don’t have to initialize _mySessionVar1. The framework uses reflection to construct the object.

Creating _mySessionVar1 is about 20 times slower than creating _mySessionVar2. Shocking? Yes. Unacceptable? No!

The reason why it is not unacceptable is that it takes 2.2 µs (microseconds) to create _mySessionVar1, and 0.12 µs (microseconds) to create _mySessionVar2. These figures include dynamically iterating the over the class members, determining their type and looking up the appropriate constructor. This is the simplified code which creates the fields at runtime:

foreach (MemberInfo member in GetType().GetMembers())
{
if (member is FieldInfo)
{
FieldInfo field = (FieldInfo) member;

ConstructorInfo constructor =
field.FieldType.GetConstructor(Type.EmptyTypes);

field.SetValue(this, constructor.Invoke(new object[0]));
}
}

Considering this happens when a web page is requested, which usually involves some database access, a little disk access and some other time-consuming stuff, a complete web page request takes between 50ms and 2000ms. Assuming we have 20 session variables to construct at runtime, the overhead is … between 0.08% (worst case) and 0.002%.

So, yes it is MUCH slower, but it doesn’t matter. (not for applications of this kind)

kick it on DotNetKicks.com
Monday, August 06, 2007 8:48:01 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3] -
 |  |  |  |  | 
# Wednesday, August 01, 2007

The other day I was checking out the Microsoft Web Client Software Factory, but I wasn’t very impressed. Too complicated, too “heavy”, too …

Anyway, I did stumble upon something interesting: it includes a class that allows you to define a class member that will survive page requests (in other words, it is stored in the session). Of course, the class can’t be used without implementing the whole framework. Too bad. But then I thought: hey, this shouldn’t be too hard to implement as a standalone class… and it isn’t. Fifty lines of code to be precise (and it takes the concept a little further than the original)

Imagine you are writing a web application, and imagine you could have a (typed) property in your class that, whenever you access it, you are actually writing to the session? Not too hard, but it requires some code:

public int CustomerID
{
   get
   {
      if (HttpContext.Current.Session["CustomerID"] == null)
         return -1;
      else
	 return (int) HttpContext.Current.Session["CustomerID"];
   }
   set
   {
      HttpContext.Current.Session["CustomerID"] = value;
   }
}

Not too bad, I know, but we can do better

How about this:

private SessionProperty<int> _customerID = new SessionProperty<int>("CustomerID",-1);

public int CustomerID
{
   get { return _customerID.Value; }
   set { _customerID.Value; }
}

The number of lines of code isn't that much lower, but it is a lot cleaner.

You can even do this:

private SessionProperty<Customer> _customer 
   = new SessionProperty<Customer>("CurrentCustomer",
                              delegate { return new Customer() });

public Customer CurrentCustomer
{
   get { return _customer.Value; }
   set { _customer.Value; }
}

In the example above, if there is nothing in the session when you first access the property, it will create a new instance of the Customer and store it in the session. No more fear for NullReferenceExceptions. Isn’t this cool?

Did I forget something? ... Yes! The code!

    
public delegate T Creator<T>();

public class SessionProperty<T>
{
private readonly string _sessionKey;
private readonly T _defaultValue;
private readonly Creator<T> _defaultValueCreator;

public SessionProperty(string sessionKey)
{
    _sessionKey = sessionKey;
    _defaultValue = default(T);
}

public SessionProperty(string sessionKey, T defaultValue)
{
    _sessionKey = sessionKey;
    _defaultValue = defaultValue;
}

public SessionProperty(string sessionKey, Creator<T> defaultValueCreator)
{
    _sessionKey = sessionKey;
    _defaultValueCreator = defaultValueCreator;
}

public T Value
{
    get
    {
	if (ProMeshHttpContext.Current.Session[_sessionKey] == null)
	{
	    if (_defaultValueCreator != null)
	    {
		T value = _defaultValueCreator();

		Value = value;

		return value;
	    }
	    else
		return _defaultValue;
	}
	else
	    return (T) HttpContext.Current.Session[_sessionKey];
    }
    set
    {
	HttpContext.Current.Session[_sessionKey] = value;
    }
}
kick it on DotNetKicks.com
Wednesday, August 01, 2007 9:27:36 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3] -
 |  | 
# Sunday, July 29, 2007

Today the ProMesh.NET project has been made public at CodePlex. ProMesh.NET is an MVC-based Web Application Framework for .NET 2.0

Features include:

  • Lightweight (<100KB) framework running on top of the ASP.NET HTTP pipeline (HttpHandler)
  • Controller-based for easy implementation of the MVC pattern
  • Flexible template-based rendering engine (using pure HTML files)
  • Very powerful integrated testing framework for running unit tests on your web pages
  • Easy mapping of parameters and other client data to typed method parameters and class members
  • Flexible and easy to use form generation and postback handling
  • Pluggable localization module (use translations from resource files, database, …)
  • Integrated logging and profiling
  • Optional integration with the CoolStorage.NET ORM library
  • Built for performance

The CodePlex project currently contains a short walk-through of the features. The code hasn’t been published yet, but will be available sometime next week.

A support forum is available for all questions about the framework.

kick it on DotNetKicks.com
Sunday, July 29, 2007 12:41:24 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [10] -
 | 
# Friday, July 06, 2007
Without going into specifics, ProMesh.NET is a web application framework based on the ASP.NET HTTP "Pipeline".

Key points about the framework:
  • Avoids the ASP.NET page model, so no ASP.NET web controls
  • Links directly into IIS using Http Handlers and Http Modules
  • Template-based system with master templates and content templates. Very powerful built-in or runtime server-generated macros can be embedded in the templates.
  • Templates can be created using off-the-shelve HTML editors like Dreamweaver and Microsoft Web Expression
  • Full control of the rendering process
  • Integrated with CoolStorage.NET
  • Built-in logging and statistics
  • ...
The project will probably be released as open source at CodePlex.

This framework has been used for internal projects for several years, including some high traffic sites like www.autosport.be and www.cartoonbase.com, so stability and performance have been proven. Now it's time to release it in the open...

kick it on DotNetKicks.com
Friday, July 06, 2007 10:35:52 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3] -
 |  |  | 
# Tuesday, June 26, 2007
Nothing really, if you use it for simple personal projects. Once you start building web applications that are a bit more complex, you start running into all kinds of problems.

What kind of problems am I talking about?
  • Building web sites in multiple languages is a major pain in the butt. Once you have 2 or more languages to support, and a few hundred pages, maintaining the resource files is hell. Especially when you are using a version management system (as you should) and have people dedicated to translating stuff.
  • The event model Microsoft magically weaved in ASP.NET is not suited for web applications. HTTP wasn't meant for a user interface framework based on events. Period.
  • Performance of the ASP.NET page rendering system is extremely slow. There are caching techniques, but these are hard to use and even harder to maintain.
  • ViewState ! Anyone who has done some serious work using ASP.NET will know exactly what I'm talking about.
  • Building standards-based websites (using CSS) is extremely hard (there are CSS "adapters" available, but they are hardly easy to use)
  • The Microsoft Ajax framework is a monster (both in size and usability)
When building web applications, I only use the first steps in the ASP.NET pipeline: Http Handlers and Http Modules. Page rendering is done using a multi-language template engine combined with a logging framework for page/session/visitor/cookie tracking.

Of course, when you don't use the ASP.NET page model, you have to know a little bit about HTTP and HTML/CSS, but I wouldn't call this a bad thing. Many web developers these days know nothing about "low level" web technology, meaning they get into trouble when something "special" or "low-level" needs to be done. I prefer to have control over the whole process: gets, posts, urls, parameters, form variables, etc.

A presentation of the framework I built will follow in my next post.

kick it on DotNetKicks.com
Tuesday, June 26, 2007 8:20:07 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [1] -
 |