Posts for #XPO

In this post I showed how nullable types can be simulated in .NET 1, especially for use with XPO. Prompted by Miha Markic, I had a look at the possibility of data binding with those simulated nullable types. I found that while the implementation I had suggested could be used without problems in a read-only situation, it obviously didn’t contain any logic that would enable editing the types via data-bound controls. Nevertheless, this is easy to do by creating a custom TypeConverter. Like this:

public class NullableInt32TypeConverter : TypeConverter {
  public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType) {
    if (sourceType == typeof(string))
      return true;
    return base.CanConvertFrom(context, sourceType);
  }

  public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value) {
    if (value is string) {
      try {
        int intVal = Convert.ToInt32(value);
        return new NullableInt32(intVal);
      }
      catch (FormatException) {
        return new NullableInt32( );
      }
    }

    return base.ConvertFrom(context, culture, value);
  }
}

In a previous article, I showed how nullable types, as implemented in version 2 of the .NET framework, can be persisted using XPO. But what if .NET 2.0 is not yet an option? .NET 1.1 doesn’t have support for nullable types and there’s no such feature in XPO, either. If somebody comes from the database world, it’s certainly understandable that types that can also be null are something he’s accustomed to. On the other hand, XPO is about persisting objects, and in that world, no ordinary value types have ever been able to have the value null. Anyhow, I do think it’s a nice feature to be able to set ints to null, certainly so when persistence to databases is considered.

So, I’ve created a nullable type together with, once again, a value converter, that allows to use nullable value types in .NET 1.1. Here’s the code for a base class and the NullableInt32:

The current version of Developer Express XPO has a Session object that handles one connection to the database together with an object cache for that session. Technically, the Session is a pivotal point in the XPO architecture, all object handling requests go through a Session object. Recently it came to my attention that some people regard it as a great problem that the Session object is tightly bound to a database connection. By default, this is a direct association: you can create more than one session object in an application, which will result in more than one database connection. If there are many clients, implemented with XPO, accessing a central database, there’ll be as many database connections as there are clients. Not necessarily a completely unusual situation, and in the domain of client/server and multi tier applications, respectively, there are numerous ways to implement things differently, if needed.

Personally, I tend to prefer application server designs these days, where things obviously scale differently in this regard. The real problem is most clearly visible when thinking about ASP.NET applications. To make XPO data available to an ASP.NET application, there are three general approaches, as detailed nicely in this article from the XPO online help:

In XPO, an ORM product by Developer Express, it’s possible to use a custom “value converter” to persist information when the standard mapping techniques are not sufficient. This provides a flexible approach that can be used in many different scenarios.

Nullable types