Centralizing mapping of user defined types

I often use CLR types for fields, such as Uri, IPAddress, SecureString and many other. Would it be possible to define these mappings once in say the LightSpeedContext? That way I can use Uri whenever I want and rest assure that it would be converted to a string as needed. This is what I had in mind:

var context = new LightSpeedContext<CloudUnitOfWork>
                                {
                                    // bla bla bla
                                };

// Define a user type for Uri using convertor UriConvertor
context.AddUserType<Uri, UriConvertor>();
// Define a user type for secure string
context.AddUserType(typeof(SecureString), typeof(SecureStringConvertor));
// Define a user type for xml
context.AddUserType(typeof(XmlDocument), typeof(XmlDocumentConvertor));
// A default convertor that can be used to convert any CLR. For example, see if it supports ISerializable and serialize to a blob
context.AddDefaultUserType(typeof(DefaultConvertor);

If my entity has a field of type Uri, then mapping automatically happens, even though I never specified that on the field itself.

class MyEntity : Entity<long>
{
      private Uri _uri;
      private XmlDocument _xml;
      private SecureString _creditcardNumber;

      /* stuff to work with the Uri */
}

Hopefully this would also allow me to map types supported by LightSpeed, such as string arrays, but which isn't supported by my database engine (aka MySQL).

Transparently handling streams with different backend storage mechanisms can be beneficial too. For example, the entity may look as follows:

class MyEntity : Entity<long>
{
    System.IO.Stream _contents;

     public System.IO.Stream Contents
     {
         get { /* */ }
         set { /* */ }
     }
}

And configure the stream to be stored in a blob field, Amazon S3, Azure Blob Storage or local file system. LightSpeed may request additional metadata in the table to determine the bucket and path of the stream of say Amazon S3. LightSpeed can support streaming for those databases that do, and emulate it for those that don't. In addition, encryption is a critical components when dealing with streams.

Currently it is a complex task to manage the streams along with the UnitOfWork life cycle. Say for example one has a 500MB blob stored in the database. Keeping a byte array of it around eats a large amount of resources. It may be better to dump it to a temporary file and return multiple stream objects, including an intermediate stream to perform decryption. Then at the end of the request, the streams are disposed and files are deleted.

One only has to look at Rugby on Rails paperclip plugin for inspiration.

refer: http://www.mindscapehq.com/forums/thread/327454