Archive

Posts Tagged ‘EntityFramework’

Magiq to Entities – An update

May 7, 2011 2 comments

The past days I’ve been working on making Magiq work with Entity Framework.

First I tried to work with the MetadataWorkspace and I gave up, ’cause its really impossible to get the mapping information. Luckily, I found Linq to Edmx project who does exactly what I needed.

Then I had some troubles working with the Queryables generated by the ObjectSets. Basically, the expression generated calls methods that doesn’t work and are there only to give information in the expression. So the expression is not something you can compile and execute. As big part of Magiq is to manipulate expression trees, that was a really big problem. I needed to figure out how to change the source queryable (I mean, the queryable where all the methods are applied to) to a simple ObjectSet. Besides it works now, I’m still working to get to a nicer way (you don’t want to know what I have done to make it work…).

Since I changed the insert API from having the new item expression (the new{…}) outside to have it as a select, I had to break the query in two, the select and the “rest”. Ok, that gave me more headaches :).

But the biggest problem was when Entity Framework started to change the order of the columns in the select (and add new columns). Let me explain how Linq to Sql works:

If you do this:

items.Where( ... ).Select( x => new { A = x.Prop1, B = x.Prop2, C = x.Prop2 /*again*/ });

Linq to sql transate it to:

SELECT prop1, prop2, prop2 FROM items WHERE ...

But Entity Framework removes the repeated columns and maybe reorders them, giving you something like:

SELECT prop2, prop1 FROM items WHERE ...

You don’t have any idea of the reflection tricks I had to make to get those property-select columns mapping.

But well, those are not bad news at all. I mean I could work around them and I can say Magiq now supports Entity Framework (with a few restrictions). Those are:

  • Only Table per class hierarchy inheritance is supported. I’m currently working on the Table per concrete class and Table per type strategies
  • Only mapped associations are supported. This means associations based on foreign keys are not (yet).
  • Only mapped POCOs are supported. This means Self Tracking entities and Code First are not (yet).

Keep in touch for the updates 🙂

Advertisements

Magiq: Next steps – different approach

April 25, 2011 Leave a comment

Back to the Magiq game!

I started to play with Entity Framework 4 and realized some stuff is not possible the way it was designed. It has to do with the way EF4 manages Lazy collections.
In Linq-to-sql and NHibernate, the collection itself has the property of being lazy, materializing all the objects when you iterate it. For example, in Linq-to-sql collections are EntitySets. Because of this, you can do this:

parent.Children.Delete(x => x.SomeCondition);

This is because the Children collection contains all the information needed:

  • The parent object instance, for getting the Id
  • The collection name

Sadly, EntityFramework handles this feature in a different way: Is the parent object the lazy one and the collection is populated when you access the collection propery and not when you iterate it. Because of that, in the moment you do parent.Children you have executed the query in the database.
This lead us to have a different API, that avoid accessing the collection property. What I thought is:

parent.Delete(p => p.Children.Where(x => x.SomeCondition));

It’s not so bad, I must Say, and it also let us do things like

parent.Delete(p => p.SomeObjectInTheMiddle.Children.Where(x => x.SomeCondition));

without executing the query for getting the SomeObjectInTheMiddle instance.

Also, I give up with Magiq-to-NHibernate, at least for a while. NHibernate has huge features, it let you map your classes in thousand of different ways, and that is awesome. But also it makes it really complicated to work with. And since NHibernate already has mass operation support, it makes sense to stop worring. At least, as I said before, for a while.

So, I will be working on changing the Query API and only for Linq-to-Sql and Entity Framework. Everyone is welcome to contribute implementations for other ORMs.

Next step: Changing the API

There’s not NH vs EF

December 25, 2009 Leave a comment

Today Ayende wrote a post about how EF is better than NH (ok, it is actually about how EF is not better than NH) and I started writing a comment about it when I realized that it was really long and it will fit better in a post. So here it is:

There are two kind of people in .NET world. The ones that likes the language and uses the framework and features following a regular OO development (people that could work in java, ruby, smalltalk, c++, etc) and the ones that does whatever microsoft says, the people that are evangelized. Don’t forget .NET is full of people that worked a lot of time with VB6 and ASP 3.

When .NET cames, it added a pretty good feature, inheritance, and people could start thinking about it. The data access was solved with datasets, that worked a lot like recordset (from the api perspective). But microsoft always suggested to use typed datasets, so developers would use strong typed properties instead of strings. A small step for man, a giant leap for mankind.

Then linq-to-sql came, so you can have objects representing your tables. Each column is “mapped” to a property. Even those foreign keys, but you have also the actual association, so you don’t need to make another select! I think they are educating people and once the developers get used to it, they could remove the fk property from the class. Baby steps, again.

I know, for NH guys all this is trivial, but try to talk about mappings, first level cache, second level cache, inheritance mapping strategies, query cache, multiple databases support, query substitutions, lazy loading, batch size, fetching strategies, custom types, etc. with someone that still thinks from the database schema perspective. Come on, there are people that writes a stored procedure for a simple insert, just because there’s a myth about the stored procedure performance!

There’s not NH vs EF. There’s NH for those that work as community does and EF for the ones that goes to church every sunday morning.

Categories: C# Tags: ,