Blog'A'Little : C#, Persistency

Persistent Objects Part 3

Einar Ingebrigtsen — Wed, 18 Aug 2004 09:50:00 GMT

The one thing I find missing in other persistent object implementations is the ability to persist data from any kind of source.

You could easily persist data from a Web Service, a dataset, other functionality found in your business logic. Just about anything, actually.

If you look at your persistent objects a bit like facade objects, this would make a lot of sense.

For instance :

[Persistent]
public class MyPersistentObject : PersistentObject
{
     [PersistentWebService("<uri for webservice>","get method","set method")]
     public string Name {
          get { return string.Empty; }
          set {}
     }
}

The DoLittle Persistency project found at GotDotNet is going in that direction. The implementation uses a PersistencySource and goes through a manager to get the Default source. The default behaviour can easily be changed by implementing your own source. This source could for instance get data from a file, if that is what you are trying to accomplish.

It's a world of opportunities.. :)

Persistent Objects Part 2

Einar Ingebrigtsen — Fri, 06 Aug 2004 16:29:00 GMT

Another aspect of creating persistent objects is the ability to design these through a visual designer such as the DataSet editor in Visual Studio. One way to go about using the same designer and get an output consisting of your objects instead of a strongly typed dataset would be to create your own custom tool.

Creating your own custom tool that generates code in Visual Studio .net 2003 is somewhat interesting. Microsoft removed or made a class private in the plugin architecture of the editor that was very helpful. The class I'm referring to is the 'BaseCodeGeneratorWithSite' base class for code generator custom tools. But a quick search on Google gives you the class along with a tutorial on how to write the plugin.
http://www.drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/

The custom tool has to implement the GenerateCode() method and do the magic. As input to this method you get the file content of the XSD file. This content can easily be transformed into whatever code you'd like. For instance, if you'd like to keep the DataSet functionality but want the dataset to be a bit smarter you can use the TypedDataSetGenerator class found in System.Data to generate a CodeDOM of the dataset and just walk this and modify the parts you want to have smarter. One thing it could do is to let all your rows have the persistent object attributes attached to it as mentioned in my other blog about Persistent Objects (http://blog.dolittle.com/PermaLink.aspx?guid=71e1b6fd-59bf-41a5-8c33-cde01dbf9899).

Persistent Objects

Einar Ingebrigtsen — Fri, 06 Aug 2004 09:21:00 GMT

One of the things that are cool with .net Framework 2.0 is the ObjectSpaces. For JAVA developers this has been available for quite some time through libraries such as Hibernate. Today you get Hibernate for .net and there is also a free Objectspaces library for .net 1.1. The only thing with both these that I really find a bit odd is that they rely on XML files to configure the classes and properties to be connected to the datasource.

The only benefit I can see from this is that DBAs can read the humanly readable XML file and just map out the DB schema for the developer to use.

Another way to go about creating a persistent object would be to do some magic in the .net framework. The remoting framework provides us with some cool features to do this a bit more fancy and smooth for the programmer. An AOP approach by using attributes is a far more sexy solution.

Let's say you have an object "Customer" and you have a property "Name" that you want to map to a table with the same name and using the column with the same name. How would the following code sound to do that trick :

[PersistentObject("Customer")]
public class Customer : ContextBoundObject
{
      [Column("Name")]
      public string Name {
           get {}
      }
}

To accomplish this, you have to use the proxy system in the remoting framework. Instead of having a server/client solution we make sure that we get a proxy no matter where it is instantiated.

We need two things to achieve this.
1. An attribute that implements the System.Runtime.Remoting.Proxies.ProxyAttribute and it's CreateInstance() method.

2. We need a proxy for the object that handles the magic.

The attribute can look something like this :

[AttributeUsage(AttributeTargets.Class)]
public class PersistentObjectAttribute : ProxyAttribute
{
    public PersistentObjectAttribute(string tableName) {
    }

    public override MarshalByRefObject CreateInstance(Type serverType) {
        PersistenceProxy proxy = new PersistenceProxy(serverType);
        return (MarshalByRefObject)proxy.GetTransparentProxy();
    }
}

The proxy could look something like this :

public class PersistenceProxy : RealProxy 
{
    public PersistenceProxy(Type type) : base(type) {
    }

    public override IMessage Invoke(IMessage msg) {
        if( msg is IConstructionCallMessage ) {
            return EnterpriseServicesHelper.CreateConstructionReturnMessage((IConstructionCallMessage) msg,(MarshalByRefObject)this.GetTransparentProxy());
        }

        // Use reflection to get the tagged properties... 
        if( msg.Properties["__MethodName"].Equals("get_Name") ) {
           return new ReturnMessage("Cool Name",null,0,null,(IMethodCallMessage)msg);
        }

        throw new NotImplementedException("Need more logic...");
    }
}

All you need to do is to create an instance of the Customer object and there you have your proxy. Ofcourse the solution for an entire system would include some factories for handling these objects from the DB and such, but the basics of it is pretty much as shown above.

Another point is that all the solutions I've seen for having persistence on objects are focused on mapping tables and columns. This can be extended to include far more features than that. How about linking a property to a WebService, an ADO DataSet, a static method on another object, a file... The possibilities are endless.

At the moment I'm working on a project that will be a fully working Component for anyone to use. You'll find it at GotDotNet :

http://www.gotdotnet.com/community/workspaces/workspace.aspx?id=0bb104cb-9ebb-4fc8-947f-2f9649f412b4

The revised version of this blog's topic can be found on TheServerSide.net : http://blog.dolittle.com/ct.ashx?id=71e1b6fd-59bf-41a5-8c33-cde01dbf9899&url=http%3a%2f%2fwww.theserverside.net%2fnews%2fthread.tss%3fthread_id%3d28325