Living in the Tech Avalanche Generation

Let’s go on a journey that takes two interesting technologies that have been to date, confined to an interoperability argument that left them barely on speaking terms. Of course I am speaking figuratively but what I’m trying to convey here is that, languages built to run on the DLR are currently limited in ways that preclude them from working seamlessly with the LINQ based ORM technologies from Microsoft, namely the Entity Framework and LINQ To SQL. This of course does not mean that languages such as IronPython are stuck in some ADO.NET void, that is not the case at all. In fact if you want to check how to use ADO.Net Data Readers etc, from IronPython I suggest check out chapter 13 of IronPython in Action (in fact if IronPython is of interest I can highly recommend the book).

Before we continue lets touch on some background. An important part of getting IronPython entities working alongside the Entity Framework, required that the Entity Framework would be calling back into our IronPython code. In recent times, a new feature was added to IronPython 2.6 which accommodated this requirement. The __clrtype__ feature allows customization of the classes that constitute the underlying CLR types for IronPython classes. If you want to find out more about this you should read the series of posts by Harry Pearson on the subject.

So with a fistful of interest in the DLR and the dynamic languages built on it, I became curious about whether the new advances and features in the Entity Framework version 4.0 combined with the addition of __clrtype__ meta class for IronPython, would bring these two technologies any closer to working together. After some pointers in a recent discussion with Michael Foord, I was willing to bet that some form of interop between the two (EF and IronPython) would now be possible; I was gambling on the added support for POCO in the Entity Framework and the customising of CLR types generated for IronPython to provide the neccessary hooks to effectively create PODO’s (Plain Old DLR Objects) that would map successfully as Entity Framework entities. Here is what I was hoping a PODO might look like.

class Customer(object):

    __metaclass__ = clrtype.ClrClass
    _clrnamespace = “EntityFramework.Podo“
    _clrfields = {  “_customerId“:str,
                    “_companyName“:str,
                    “_contactName“:str
                 }

    @property
    @clrtype.accepts()
    @clrtype.returns(clr.GetClrType(str))
    def CustomerID(self):
        return self._customerId

    @CustomerID.setter
    @clrtype.accepts(clr.GetClrType(str))
    @clrtype.returns()
    def CustomerID(self, value):
        self._customerId = value

    @property
    @clrtype.accepts()
    @clrtype.returns(str)
    def CompanyName(self):
        return self._companyName

    @CompanyName.setter
    @clrtype.accepts(str)
    @clrtype.returns()
    def CompanyName(self, value):
        self._companyName = value

    @property
    @clrtype.accepts()
    @clrtype.returns(str)
    def ContactName(self):
        return self._contactName

    @ContactName.setter
    @clrtype.accepts(str)
    @clrtype.returns()
    def ContactName(self, value):
        self._contactName = value

First up, I guess that in a pure sense this is not so compliant in the P part of PODO right? The Decorators on our functions do bleed out the technology a little but I am not going to let the goal get hung up on this point.

My initial thoughts also considered that with Code Only mapping I might be able to do away with any need to provide any supporting infrastructure code created in a statically typed language (C# or VB.NET).

In Part 2.0 of this series of posts we will start the journey in earnest and see what successes and hurdles we hit along the way. Rather than keep you waiting to find out whether this is all going to end well and keep you dangling under false pretences, let me just say that it partially works. The fact that it partially works gives me hope the rest of this series might help uncover or encourage a way to make these two technologies work together in a more complete way.