I have recently published a few more XPO related posts on the new Developer Express community site. Previously I have sometimes posted XPO stuff on this blog, and these posts are now all eaten up by the DX site – so I thought I’d let you know if you’re watching this space and not the DX community site.

Here are the posts I wrote:

• Session Management and Caching
• My persistent classes are real classes – or not?
• Relations and custom collections
• Advanced queries
• XPO is good for distributed applications

I recommend watching at least the XPO related blog if you are interested in this, as I can’t promise I’ll always find the time to notify readers of this blog about posts in the other. The main page of the XPO blog is here, and there are links available for RSS and Atom aggregation.

This has been announced today: There’s a Developer Express site now for blogs written by people working for the company.

This is it: community.devexpress.com

I have published two posts there so far, related to the newest major release of XPO (6.1): “Session Management and Caching” and “My persistent classes are real classes – or not?”.

I have just published this: Transactions and Units of Work

The next version of XPO (eXpress Persistent Objects) from Developer Express has finally been released. A list of new features is here. I’m currently working on a number of technical articles that will soon start to appear in the list on this page – look out for that if you’re into XPO. And if you’re not (yet), be sure to download a demo of the complete suite including XPO from here.

Well, if I’m wondering about that every now and then, I’m sure some of the more loyal readers of my blog must be wondering the same thing, given the sparse nature of blog updates in recent months. The answer is, since I’ve started working for Developer Express, I’ve been doing that many different things that it’s just hard to keep track of them, and I haven’t found myself with the free time needed to continually update my blog. But I see that this is a Bad Thing™ and I’ll try to do something about it.

So what have I done? Let’s see:

• I’ve worked on concepts, testing, samples and documentation of eXpressApp Framework, which was made available as a CTP on January 12th. Since then we’ve been getting great feedback from our subscribers (who have access to the CTP) and I’ve spent a lot of time investigating issues, exchanging posts with customers and coordinating things with our development teams. Obviously development has continued since we released the CTP version, so even more plans to be made…
• Since the beta of XPO 2 came out, I’ve spent a lot of time with customers testing this product, and also with internal discussions about the final feature set, some article writing, sample explaining, …. As with eXpressApp Framework, feedback has been great and we’ll be able to make the final product a lot better even than the beta was. Just recently I wrote a DXCore plugin to support XPO 2 in the final release… I hope that feature will actually make it. And no, I’m not telling what it is
  Obviously XPO 2 is an important base of eXpressApp Framework, so we need to be careful to coordinate things between these two projects.
• XtraCharts and the XtraLayout control have also been released into their beta phases and I’ve done some testing on these releases. Specifically XtraLayout is another important component in the Windows Forms part of eXpressApp Framework.
• I created a DXCore plugin that can store my Window/Tool Window configuration in VS and restore it later - very nice to work with multiple window configurations. For example, on my multi-monitor setup I typically use VS stretched over two of the three screens. But when I just want to edit some XML, I like to have the window on only one screen and get rid of most of the tool windows I normally use.
  I offered making this plugin available in the DXCore plugins newsgroup, but as I got only one reply to that post, I haven’t taken the time yet to actually do this. Drop me a mail if you want to vote for having this plugin available as a download
• I’m currently working on a DXCore plugin that will let me ink on my VS editor with my Tablet PC.

• I’m currently working on an article about DXCore for German dot.net magazin. Not sure when that will be published.
• DevWeek 2006 is here in London Feb 20-24. Looks like I’m going to be there - if you’re around, feel free to drop by the Developer Express booth for a chat.
• As far as I know, I’m going to do a talk about CodeRush and Refactor! at the March 14 meeting of The Developers Group in Hammersmith. Their official agenda for that day is not yet up, that’s why I’m saying "as far as I know" Should be interesting though - the talk will not be too long and it will provide an overview over functionality offered by these two great products.
• Several other things I can’t currently tell about

Recently, there have been several requests in the XPO newsgroup about problems with serialization, in conjunction with ASP.NET. I’m still unclear if these issues all had the same sources, but when somebody approached me personally about this today, I thought I’d just look into the web services problem. Please note that I made these tests on the .NET 2 platform, so there may be differences to .NET 1.1. What’s more, ASP.NET and web services are not something I usually have much to do with, so I may certainly be missing something here and there.

Now, what is the problem? Simple: If you have a web method that returns a type that’s derived from one of the XPO base classes (XPObject or XPCustomObject, doesn’t matter), an exception will be thrown when you try to access the service:

InvalidOperationException: DevExpress.Xpo.XPDeletedObject cannot be serialized
because it does not have a parametless constructor.

(Editor: DevExpress, if you’re reading, how about fixing that message? )

Similarly, if you try to return an XPCollection, the following exception will be thrown:

NotSupportedException: Cannot serialize interface DevExpress.Xpo.IXPSimpleObject.

So, at a glance one could think that XPO is completely incompatible with web services for these simple reasons. Well… not.

IXmlSerializable

Because web services use XML (SOAP) serialisation to transfer data from one point to another, it’s important that any complex data objects you want to transfer must be convertible by the standard mechanisms. The exception that’s shown for the XPObject return type tells us that there’s a problem with one of the types referenced by one of the base classes - the standard mechanism gives up at that point. To enable conversion of the object’s data to XML, we need to override the defaults and provide our own implementation of the XML creation code. Here’s a simple XPO data class that creates its own XML code for serialisation:

public class DataObject : XPObject, IXmlSerializable {
  public DataObject() { }
	
  public DataObject(int index, string strVal) {
    this.index = index;
    this.strVal = strVal;
  }
	
  private int index;
  public int Index {
    get { return index; }
    set { index = value; }
  }
	
  private string strVal;
  public string StrVal {
    get { return strVal; }
    set { strVal = value; }
  }
	
  void IXmlSerializable.WriteXml(XmlWriter writer) {
    writer.WriteElementString("Index", XmlConvert.ToString(index));
    writer.WriteElementString("StrVal", strVal);
  }
	
  void IXmlSerializable.ReadXml(XmlReader reader) { }
	
  XmlSchema IXmlSerializable.GetSchema() { return null; }
}

Now a method that returns an object of type DataObject will render the following nice XML code when invoked via the web service (and the exception will be gone):

<?xml version="1.0" encoding="utf-8"?>
<DataObject xmlns="http://sturmnet.org/">
  <Index>42</Index>
  <StrVal>One entry</StrVal>
</DataObject>

Type information

The main remaining problem with this is that the WSDL code for the web service will still not contain a type definition for the complex type, so on the consuming side access to the data isn’t as easy as on the service side. To provide the web service with type information that can be used for WSDL generation, the object that implements IXmlSerializable must also deploy the XmlSchemaProvider attribute (this is new in .NET 2.0, I think in 1.1 the GetSchema method of the interface should be used, which is deprecated in 2.0). This attribute defines a static method in the class that must add XML Schema information to the schema set used by the XML serialiser. With that in place, the example class looks like this:

[XmlSchemaProvider("XmlSchema")]
public class DataObject: XPObject, IXmlSerializable {
  ...
	
  public static XmlQualifiedName XmlSchema(XmlSchemaSet xmlSchemaSet) {
    XmlSerializer schemaSerializer = new XmlSerializer(typeof(XmlSchema));
    StringReader reader = new StringReader(Resources.DataObject);
    XmlSchema schema = (XmlSchema) schemaSerializer.Deserialize(reader);
    xmlSchemaSet.Add(schema);
	
    return new XmlQualifiedName("DataObject", "http://sturmnet.org/DataObject");
  }
}

The schema itself, which I’m simply loading from a resource in this case, looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="DataObject"
                  targetNamespace="http://sturmnet.org/DataObject"
                  elementFormDefault="qualified"
                  xmlns="http://sturmnet.org/DataObject"
                  xmlns:mstns="http://sturmnet.org/DataObject"
                  xmlns:xs="http://www.w3.org/2001/XMLSchema">
	<xs:element name="DataObject" type="DataObject" />
	
	<xs:complexType name="DataObject">
		<xs:sequence>
			<xs:element name="Index" type="xs:int" />
			<xs:element name="StrVal" type="xs:string" />
		</xs:sequence>
	</xs:complexType>
</xs:schema>

Now the object can pass the important type information on to the WSDL generation process, and on the consumer side a proxy class will be created automatically to deserialise the data from the XML code. Obviously, creating this code for every data class manually would probably be a lot of work. Using the elaborate type information that XPO collects about its data classes, it should be quite easy to implement generic methods that can output reasonable standard XML code and schema definitions for every XPObject. For now, I’m leaving this as an exercise for the reader.

The collection return type

The final issue is that it’s still not possible to have a web method return a complete XPCollection. To work around this, there are two possible solutions:

1. Create your own collection type, possibly derived from XPCollection, implement IXmlSerializable on that and handle it like a complex type in its own right. This is the most flexible approach, but it’s also a lot of work. Maybe better to
2. Have the method return a normal array type instead of the complex type. These types work just fine in .NET and they can be handled out of the box by the standard mechanisms.

Using approach (2), a method returning a collection of DataObjects could look like this:

[WebMethod]
public DataObject[] GetData() {
  XPCollection coll = new XPCollection(typeof(DataObject));
  return (DataObject[]) ArrayList.Adapter(coll).ToArray(typeof(DataObject));
}

This works just fine with the XML serialisation support already implemented in the single DataObject, so a list of objects may look like this (in XML, there’ll be a wonderful DataObject[] type in the consumer proxy):

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfDataObject xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://sturmnet.org/">
  <DataObject>
    <Index>42</Index>
    <StrVal>One entry</StrVal>
  </DataObject>
  <DataObject>
    <Index>52</Index>
    <StrVal>Another entry</StrVal>
  </DataObject>
</ArrayOfDataObject>

So, I hope this will prove helpful - have fun!

Many things change with the decision to work with purely object-oriented data in a specific situation. The outlook seems good: business processes and rules will be much easier to implement, completely typed data will be no problem at all and there’ll be no more structural problems trying to accomodate clumsy handling of records and rows in an otherwise OO application structure. There’ll be an object/relational mapping tool that takes care of all the persistence issues. There’s one thing though that will pose problems much greater than originally anticipated, and it’s easy to overlook large parts of that in the original decision: the wide topic of data integrity in the object world (OW).

I’m going to present some general questions and theories about data integrity in conjunction with OO data objects in this article and I’m planning to write some further articles on the same topic later. Occasionally I may reference the technology I’m personally using at the moment, which is .NET 2, the C# language and XPO.

Data integrity, what about it?

First of all, data integrity comes in two flavours:

1. The technical side of things is where we are talking about referential integrity on a database level, mapping of field types between databases and programming languages, things like that.
2. The logical part is part of what’s often referred to as Business Logic. There are definitions for value ranges, maximum counts of assignments between objects, valid states of object fields and much more. Obviously, business logic in its whole may encompass lots of other things, the part that’s relevant here is only where it relates to object data in the objects, as opposed to object data in flow between objects and states.

Many aspects of both data integrity parts are very different in the OW, compared to a “simple” relational database model.

Why is it different?

People have been thinking about these issues for the relational database scenario for a long time. Concepts like referential integrity and unique indexes are very important in this domain. Normalisation provides for database configurations where automated referential integrity can be fully exploited. Databases have features that let the designer restrict values, together with modern database access layers like ADO.NET the complete technical side of data integrity and possibly some of the logical part is covered by these mechanisms.

In the OW, this is where the problems start. Obviously, a good o/r mapping tool should be able to exploit the features of the database layer, but this isn’t sufficient. As soon as a single object is mapped to more than one table (as it should be, when inheritance is used), many of these mechanisms break. For example, it’s impossible to define a multi-value index, unique or not, for values that are not in the same table. Depending on implementation details of the o/r mapper, even unique indexes over fields that are in the same table may present problems, for example if the mapper doesn’t make sure that all necessary fields of an object are filled (correctly!) before the object is first saved to the database.

When working directly with relational databases, the easy way to implement business logic is on the server side. Using triggers on the database level, consistency checks can be implemented, other processes executed just in time and so on. Unfortunately, this has a lot of drawbacks; one of the worst is that there’s no easy way to get useful user feedback in case a check fails. In real-world applications, more often than not business logic implementations will be split, performing some kinds of actions on the database level while leaving other stuff to the client application. For the latter part, it’s difficult to find the right “place” where to implement it, in .NET a typed dataset can provide part of a useful answer.

As long as there’s any server-side consistency checking implemented, there’s always the problem that data which is already loaded on the client, and has been changed there, may not adhere to the same restrictions the server would enforce if the data was to be saved. The programmer has to keep an eye on the exact state of things and see to it that data is saved to the server in all the right places.

There are two aspects to this issue: First, an o/r mapping tool should be allowed to define it’s own database structure with as much freedom as possible. (I know that a lot of people think that this should work the other way round, letting them define a structure and leave the tool to deal with that. Apart from situations where one needs to work with legacy data structures, this is nonsense to me and contorts the purpose of such tools.) Obviously, I’d have to be very careful when writing database layer code that successfully uses the information in the generated layout, and I’d risk breakage every time I update the tool.

Second, from the OW point of view, it seems intolerable to have a number of objects in memory at any given time that may not be in a consistent state. With relational data, this is often a situation that’s simply left to the developer of each distinct algorithm. But when objects are global to the application (or parts of it, at least) and there are intelligent caching and lifecycle management mechanisms in place, as implemented by a useful o/r mapper, one can’t live with the possibility of inconsistent states in in-memory data.

Consequences

So, these are (some of) the specific issues we have to deal with in the OW:

1. The consistency of in-memory data has much greater importance in the OW. Also, in-memory data is probably a more common thing to have to deal with.
2. Standard mechanisms on the database layer may be partly useless and there’s no ready-made replacement. Client-side counterparts like the index support in .NET datasets are not immediately available.
3. While obviously consistency checking systems like those implemented in triggers on a database server can be implemented client-side in an object framework, there’s no fixed point where this can be implemented. Everybody knows what a “before insert” trigger in a database is good for, but where do I put the same code in my OW?

These issues and their solutions will be subjects of future posts. Thanks for reading so far!

In this post I showed how nullable types can be simulated in .NET 1, especially for use with XPO. Prompted by Miha Markič, 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);
  }
}

To activate this type converter for the NullableInt32, you have to decorate the NullableInt32 class with an attribute:

[TypeConverter(typeof(NullableInt32TypeConverter))]
public class NullableInt32 : Nullable {
  public NullableInt32( ) : base(false) { }
  ...

Now you can bind a collection of objects, which contain properties of the type NullableInt32, to a grid and edit the value for the NullableInt32 property. Just enter an invalid or empty string to set the value to null.

Update: Miha pointed me to this obviously more complete implementation of nullable types for .NET 1. I haven’t had a close look at them because my platform is .NET 2 anyway, so I can’t say anything about the implementation, but obviously the main purpose of this post was to show a way of implementing this kind of thing with XPO. I guess that information in usable with the sourceforge implementation of nullable types just the same.

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:

public abstract class Nullable {
  public Nullable(bool hasValue) {
    this.hasValue = hasValue;
  }
	
  private bool hasValue;
  public bool HasValue {
    get { return hasValue; }
    set { hasValue = value; }
  }
	
  public override string ToString( ) {
    return hasValue ? "" : "(null)";
  }
}
	
public class NullableInt32 : Nullable {
  public NullableInt32( ) : base(false) { }
	
  public NullableInt32(Int32 value) : base(true) {
    this.value = value;
  }
	
  private Int32 value;
  public Int32 Value {
    get { return value;	}
    set {
      this.value = value;
      HasValue = true;
    }
  }
	
  public override string ToString( ) {
    return HasValue ? Value.ToString( ) : base.ToString( );
  }
}

When writing these classes, I made the design decision not to implement the object’s value in the base class. Of course, each derived class needs more code because of that, but I avoid a lot of boxing/unboxing (David Cumps has some useful info on that), which might be worthwhile in this context.

The other decision I made was to use a class as opposed to a struct. Using a struct would be a good idea because we wouldn’t need to add a line to the constructor of the data object to get the object initialised. But then we’d have to implement all the functionality in every single nullable type, because there’s no such thing as an “abstract base struct”. By the way, the .NET 2.0 nullable types are implemented using structs, but that’s only made possible by the .NET 2 support for Generics. Something to add to my recent article, I guess

Now we need a value converter to properly store this type into a single field in the database:

public class NullableInt32ValueConverter : ValueConverter {
  public override Type StorageType {
    get { return typeof(Int32);	}
  }
	
  public override object ConvertToStorageType(object value) {
    NullableInt32 val = value as NullableInt32;
    return val.HasValue ? (object) val.Value : null;
  }
	
  public override object ConvertFromStorageType(object value) {
    NullableInt32 result = new NullableInt32( );
    if (value != null)
      result.Value = (Int32) value;
    return result;
  }
}

A data class that uses this type might look like this:

public class DataClass : XPObject {
  public DataClass( ) {
    intVal = new NullableInt32( );
  }
	
  NullableInt32 intVal;
  [ValueConverter(typeof(NullableInt32ValueConverter))]
  public NullableInt32 IntVal {
    get { return intVal; }
    set { intVal = value; }
  }
}

When this data class is persisted, it will use a single database field that’s set to null if the nullable int field doesn’t hold a value.

Of course, this implementation isn’t as elegant as that in .NET 2.0, which makes use of the advantages of Generics and native nullable types. But it’s certainly usable if you tuck away the different NullableXXX classes (created like the one above) and the value converters in a helper assembly. It’s also possible to register a value converter for a specific type globally, so you don’t have to decorate each property with the ValueConverterAttribute. In that case, just make sure to call the registration method before you do any persisting or loading on the XPO data.

Session.DefaultSession.Dictionary.RegisterValueConverter(
  new NullableInt32ValueConverter(), typeof(NullableInt32));

Update: Miha pointed me to this obviously more complete implementation of nullable types for .NET 1. I haven’t had a close look at them because my platform is .NET 2 anyway, so I can’t say anything about the implementation, but obviously the main purpose of this post was to show a way of implementing this kind of thing with XPO. I guess that information in usable with the sourceforge implementation of nullable types just the same.

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: (a) one global XPO session, (b) one XPO session per ASP.NET session and (c) one XPO session per request. There isn’t much to say (apart from what’s already said on that page) about (a) and (c), but (b) is of interest: while it seems to be the perfect solution in terms of manageability (certainly better than (a)), it has its drawbacks where performance is concerned because the multiple Session objects can’t share an object cache and, much worse, because the lifetime of an XPO session also defines the lifetime of a database connection.

Of course it would be nice if the session had a mechanism that would simply drop the current connection every time it’s finished using it. With connection pooling, as employed by default by the SqlClient, the overhead for getting a new connection would be small but resources could be used much more efficiently when database connections would only be acquired if (and for the time they are) needed. This functionality is missing in the current XPO version. It could be relatively easy to make the necessary changes in the XPO source code, I’m still looking into this.

Until that point, there’s a simple solution that works nicely in many cases: When the database connection that’s used for a session is closed, that connection is returned to the connection pool and can be reused elsewhere. Interesting enough, XPO already contains the code that will re-establish the connection before it’s needed the next time. The important thing is that you must use a line like this:

// close the inner connection
mySession.Connection.Close();

This is not the same thing as mySession.Disconnect();! You’ll need to add a line like that in all places where you know that your work with the session has been done for the moment. It’s very well possible, for example, to access the session to build a collection of objects, make sure they’re loaded (e.g. by accessing one of them), close the connection and continue to work with the objects! There’s nothing much that can go wrong here because XPO will always re-establish the connection if it’s needed after all.

In a simple test I made, this approach worked nicely in the ASP.NET scenario I was talking about. I restricted the connection pool to two connections and I was able to access the application with five clients nevertheless, because connections were reused from the pool by all five Session objects.

I hope this will prove helpful for someone!

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

Although the Developer Express knowledge base provides an article that shows how to persist a bitmap, I had never actually used that approach. With .NET 2.0, I was thinking about persisting nullable types and I found that XPO 1 doesn’t have support for that out of the box. The support guys sent me a sample showing how a value converter can be used to extend the mapping to include nullable types. I extended that code to create a generic value converter that can be used for any nullable type. Here’s the code for that:

  public class NullableValueConverter<T> : ValueConverter where T: struct {
    public NullableValueConverter( ) {
      storageType = typeof(T);
    }
	
    private Type storageType;
    public override Type StorageType {
      get { return storageType; }
    }
	
    public override object ConvertToStorageType(object value) {
      Nullable<T> nullableValue = (Nullable<T>) value;
      return nullableValue.HasValue ? (object) nullableValue.Value : null;
    }
	
    public override object ConvertFromStorageType(object value) {
      return (Nullable<T>) (value == null ? null : value);
    }
  }

Now how do you use that thing? It’s simple: just decorate a property that has a nullable type with the ValueConverterAttribute:

  private int? intVal;
  [ValueConverter(typeof(NullableValueConverter<int>))]
  public int? IntVal {
    get { return intVal; }
    set { intVal = value; }
  }

With newer versions of XPO (I’m not sure if that feature is in any released version yet, if it isn’t and you want it (and you are a customer), feel free to send mail to support@devexpress.com) you can also register the value converter for a type globally, so all properties of that type will be converted automatically. Here’s how:

  Session.DefaultSession.Dictionary.RegisterValueConverter(
    new NullableValueConverter<int>(), typeof(int?));

Unknown types

The second interesting use of the value converter was something I stumbled upon a few days later. I had a field in a class that should have been persisted, but I really didn’t know what that field might contain later on. The information would be sent to a server via Remoting and the type depended on the client implementation, so I could only use “object” as the type for the field. Now, how would I go about persisting this information?

The solution I found was to create a value converter that uses serialization to persist the object into a string field. Of course, the object has to be Serializable for this to work, but that’s a requirement for the Remoting part anyway, so I didn’t care. With my SerializableObjectConverter it’s possible to decorate a property like this:

  private object data;
  [ValueConverter(typeof(SerializableObjectConverter)), Size(SizeAttribute.Unlimited)]
  public object Data {
    get { return data; }
    set { data = value; }
  }

And here’s the code for the SerializableObjectConverter:

public class SerializableObjectConverter : ValueConverter {
  public override Type StorageType { get { return typeof(string); } }
	
  public override object ConvertToStorageType(object value) {
    Assert.Check(value.GetType().IsSerializable,
      String.Format("The given object ({0}) is not serializable.", value));
	
    string result = null;
	
    MemoryStream stream = new MemoryStream();
    try {
      SoapFormatter formatter = new SoapFormatter( );
      formatter.AssemblyFormat = FormatterAssemblyStyle.Simple;
      formatter.Serialize(stream, value);
      result = Encoding.Default.GetString(stream.GetBuffer( ));
    }
    finally {
      stream.Close();
    }
	
    return result;
  }
	
  public override object ConvertFromStorageType(object value) {
    object result = null;
	
    MemoryStream stream = new MemoryStream(
      Encoding.Default.GetBytes((string) value));
    try {
      stream.Position = 0;
      SoapFormatter formatter = new SoapFormatter();
      formatter.AssemblyFormat = FormatterAssemblyStyle.Simple;
      result = formatter.Deserialize(stream);
    }
    finally {
      stream.Close();
    }
	
    return result;
  }
}