We are planning to migrate from NHibernate to Entity Framework 4. We have like a zillion classes and mappings, which will take ages to insert them by hand in LLBLGen. Is there a way to import the .hbm.xml files as the model, whereafter LLBLGen can be used to further manage the model-structure; so we can easily create a new layer based on EF4?

not yet, we're working on an import system for 3.1: the foundation of the import system has to be in place for 3.1 and 1 or more importers have to be shipped with 3.1, it's to be seen if we can get NH import working before 3.1, it will otherwise be in 3.2.

In the meantime, you do have a DB currently, I recon?

If you reverse engineer from the DB to a new project, and before reverse engineering the entities etc. you specify the patterns for names etc. properly in the project properties, you should get up and running in no time. You can then refactor the entities you have with complex types ('value types') in the designer to group fields into value types.

That's the model part. The code generation part, where you define the entity classes etc., I think you want to keep your NH POCO classes? Or do you plan to start over with new classes? In case of the former, we have a template set for EFv4 which generates the context and EDMX, though you of course have to make sure the types in the model match your classes.

Otis wrote:

not yet, we're working on an import system for 3.1: the foundation of the import system has to be in place for 3.1 and 1 or more importers have to be shipped with 3.1, it's to be seen if we can get NH import working before 3.1, it will otherwise be in 3.2.

Have you got any timeline for future LLBLGen releases available?

In the meantime, you do have a DB currently, I recon?

If you reverse engineer from the DB to a new project, and before reverse engineering the entities etc. you specify the patterns for names etc. properly in the project properties, you should get up and running in no time. You can then refactor the entities you have with complex types ('value types') in the designer to group fields into value types.

Reason for using the NHibernate files as a base, is that almost all our entities aren't a one-on-one mapping to our database tables; ergo: loads of time.

That's the model part. The code generation part, where you define the entity classes etc., I think you want to keep your NH POCO classes? Or do you plan to start over with new classes? In case of the former, we have a template set for EFv4 which generates the context and EDMX, though you of course have to make sure the types in the model match your classes.

Yes, POCO classes should stay the same; mapping and DAO's will probably be replaced. Not really sure whether we will move to EF4 or NHibernate 3 (if it ever gets final), but that would be the beauty of LLBLGen. We first want to get some more maintainable model.

Jan wrote:

Otis wrote:

not yet, we're working on an import system for 3.1: the foundation of the import system has to be in place for 3.1 and 1 or more importers have to be shipped with 3.1, it's to be seen if we can get NH import working before 3.1, it will otherwise be in 3.2.

Have you got any timeline for future LLBLGen releases available?

3.1 should go beta in december/january, depending on how much time the important new features take.

In the meantime, you do have a DB currently, I recon?

If you reverse engineer from the DB to a new project, and before reverse engineering the entities etc. you specify the patterns for names etc. properly in the project properties, you should get up and running in no time. You can then refactor the entities you have with complex types ('value types') in the designer to group fields into value types.

Reason for using the NHibernate files as a base, is that almost all our entities aren't a one-on-one mapping to our database tables; ergo: loads of time.

You mean, entity X is mapped on table T1 but has base class A which isn't mapped, entity Y is mapped onto table T2 and has no base class, etc. ?

It's not important if some fields in the table aren't mapped or some properties in the class aren't mapped, that's ok. The main thing is whether you have classes which are mapped onto joins if tables, direct SQL, multiple tables without using inheritance in the database (class inheritance isn't a problem)

Per entity the base class (which might not be an entity) can be specified, so that's not a problem. The main point is I think what you mean exactly with 'aren't a 1:1 mapping to our db', could you give an example?

That's the model part. The code generation part, where you define the entity classes etc., I think you want to keep your NH POCO classes? Or do you plan to start over with new classes? In case of the former, we have a template set for EFv4 which generates the context and EDMX, though you of course have to make sure the types in the model match your classes.

Yes, POCO classes should stay the same; mapping and DAO's will probably be replaced. Not really sure whether we will move to EF4 or NHibernate 3 (if it ever gets final), but that would be the beauty of LLBLGen. We first want to get some more maintainable model.

In EF4, the conceptual model in the EDMX contains the names of fields + classes, and these have to be the same as the entity names + field names in the entity. So if you define an entity Customer in the model, you can't have a class CustomerTypeClassImpl as it has to be named equal in code as in the EDMX file. This might be a tricky part.

If I could get a better picture how the classes relate to the db model it would be easier to answer whether it will work out or if it will be a long struggle.

You mean, entity X is mapped on table T1 but has base class A which isn't mapped, entity Y is mapped onto table T2 and has no base class, etc. ?

It's not important if some fields in the table aren't mapped or some properties in the class aren't mapped, that's ok. The main thing is whether you have classes which are mapped onto joins if tables, direct SQL, multiple tables without using inheritance in the database (class inheritance isn't a problem)

Per entity the base class (which might not be an entity) can be specified, so that's not a problem. The main point is I think what you mean exactly with 'aren't a 1:1 mapping to our db', could you give an example?

F.e. we have a heavily denormalized table, so NHibernate gets 1 row and 200 columns. Now this row should be normalized so we can use it in our frontend.

Class A gets a couple of properties, and 3 instances of Type B, and 2 instances of Type C, and another instance of Type D and one from Type E. Mainly what you can do with the '<component/>' tag in NHibernate. All based on those 200 columns.

This way we don't have to do any join'ing in our read-heavy frontend.

Jan wrote:

You mean, entity X is mapped on table T1 but has base class A which isn't mapped, entity Y is mapped onto table T2 and has no base class, etc. ?

It's not important if some fields in the table aren't mapped or some properties in the class aren't mapped, that's ok. The main thing is whether you have classes which are mapped onto joins if tables, direct SQL, multiple tables without using inheritance in the database (class inheritance isn't a problem)

Per entity the base class (which might not be an entity) can be specified, so that's not a problem. The main point is I think what you mean exactly with 'aren't a 1:1 mapping to our db', could you give an example?

F.e. we have a heavily denormalized table, so NHibernate gets 1 row and 200 columns. Now this row should be normalized so we can use it in our frontend.

Class A gets a couple of properties, and 3 instances of Type B, and 2 instances of Type C, and another instance of Type D and one from Type E. Mainly what you can do with the '<component/>' tag in NHibernate. All based on those 200 columns.

This way we don't have to do any join'ing in our read-heavy frontend.

Entity framework doesn't support entity mapping through 'complex type mapping' (component) like NHibernate does, though it does support value types (as we do in the designer).

So if the denormalized row is stored in an entity A which has properties of type X, Y and Z, and X, Y and Z are value types ('Complex types' in EF) it will work. You can refactor 'A' to have these properties using the designer, please see: http://www.llblgen.com/Pages/Files/Videos/LLBLGenProv3.0_EF_DBFirst.html and skip to 3M24 to see the refactoring.

When generating code, you can then opt for not generating classes, only the EDMX and context, so you can re-use your own classes. A HTML page is emitted as well with per type the fields and their .net types so this would make it easier to implement / keep track of your own code and what types the fields have to have.

I'm not sure if you use Entity types as Components in NHibernate (and thus save them individually) as that's not supported in Entity framework and also not in our designer.