views:

65

answers:

2

Hi all,

Using Microsoft's designer for the Entity Framework (v3.5), I have created an Entity Model (*.edmx) with a generated *.Designer.cs class. I can persist my objects to MS SQL Server using the model without any problems.


I am new to NHibernate, and out of curiosity, I now would like to use my model with Fluent NHibernate and SQLite as database. I have read the Auto mapping article on the Fluent NHibernate wiki. I did adapt the Examples.FirstAutomappedProject and have adapted the ExampleAutomappingConfiguration to map my entities. (I used only the ShouldMap and IsId overrides). My entities are rather simple and do not contain explicit references to each other in the model.
Now, when I build the Session Factory, i get the following exception:

An invalid or incomplete configuration was used while creating a SessionFactory. Check PotentialReasons collection, and InnerException for more detail.

with an inner exception with the message

An association from the table XXX refers to an unmapped class: System.Data.EntityKey

None of my entities' properties are of type System.Data.EntityKey.

[global::System.Data.Objects.DataClasses.EdmEntityTypeAttribute(NamespaceName="MyStorageModel", Name="XXX")]
[global::System.Runtime.Serialization.DataContractAttribute(IsReference=true)]
[global::System.Serializable()]
public partial class XXX: global::System.Data.Objects.DataClasses.EntityObject
{
  //...
     [global::System.Data.Objects.DataClasses.EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
     [global::System.Runtime.Serialization.DataMemberAttribute()]
     public global::System.Guid XXXID
     {
        //...
     }
  //...
}

As you see, my entity classes are heavily decorated (by the used designer of course) with a attributes that probably refer to this type. Can this cause these troubles?

+1  A: 

The problem probably is that your entity is inherited from EntityObject. EntityObject declares two public properties: EntityKey and EntityState. EntityKey is of type EntityKey and it is handled like association to class which you didn't provide to NHibernate. I think you will not be able to do this unless you use EF 4.0 and POCO which didn't inherit from EntityObject.

Ladislav Mrnka
Thanks. I have been able to verify the association to EntityKey. So far, this really prevents me from using these entities. Since the entities do come from a real project I can not alter that just because of my "curiosity on NHibernate" right now. and EF4.0 is only CTP yet.
Marcel
No EF 4.0 is not in CTP. EF 4.0 is part of .NET 4.0 which was already released.
Ladislav Mrnka
@Ladislav: You are right, I had the Code First Approach in my mind when writing the comment.
Marcel
+1  A: 

Using the database first EntityFramework code generation wizard will generate model classes that are tightly coupled to EntityFramework and that can't easily be used with NHibernate.

To make things worse, EntityFramework 3.5 doesn't really support POCO objects which would (likely) work with NHibernate. EF 4.0 has much better POCO support, but ultimately I'm not sure it would work as you want it to.

I would throw away the EntityFramework model classes and start over if you really want to work with Fluent NHibernate.

Here are some questions related to NHibernate model class code generation:

http://stackoverflow.com/questions/41752/nhibernate-generators http://stackoverflow.com/questions/1578341/what-is-the-best-code-generator-for-nhibernate

Michael Maddox
Thanks for your answer. It's sad, but currently I can not change the model since it is from production code in use. And later, when retrieving the entities back from the storage I want to feed them back into the real application not to some test version.
Marcel
@Marcel: I don't understand why you think you need to use your EF model classes "underneath" NHibernate. You could put another layer of POCO model classes on top of EF that are usable by NH. Or you can create a second set of model classes that are peers of the EF model classes that work with NHibernate. You may need to do something like this anyway if you eventually want to get away from EF 3.5. In any case, model classes should be agile just like every other piece of software in the system and saying they are set in stone makes me question the policies in place where you work. Good luck.
Michael Maddox

related questions