I have a question regarding the upcomming V3 of LlbgenPro and support for multiple ORM runtime (Llblgen, EF, NHibernate...):

I understand that from your entity model, you will be able from V3 to generate datal layers on top of the ORM of your choice. What about the generated business layer? Will it be the same for all ORMs? In other words: can I use the generated DataLayer transparently and independently from which ORM runtime has been selected?

I guess answer will be yes, but would like confirmation. If you did it, I don't know how... But you're a genius Frans, I hope you did it as it will really be a amazing capability

Kind Regards, Walter Almeida

We're not generating a Business layer, just code to use the O/R mapper chosen. So if you pick EF4, you'll get classes and the context of EF4, or poco classes and the context, etc. Not a layer which is on top of that. You could create that of course, but the code generated is designed to match the framework chosen, not some generic layer on top of it, so nhibernate's classes will be different from EF's classes and LLBLGen Pro classes, simply because nhibernate users work differently.

Otis wrote:

We're not generating a Business layer, just code to use the O/R mapper chosen. So if you pick EF4, you'll get classes and the context of EF4, or poco classes and the context, etc. Not a layer which is on top of that. You could create that of course, but the code generated is designed to match the framework chosen, not some generic layer on top of it, so nhibernate's classes will be different from EF's classes and LLBLGen Pro classes, simply because nhibernate users work differently.

Hello Frans,

OK, makes sense. Still would probably be interresting to have a generic layer on top of the ORM. I am trying to see the benefits of such a generic layer... Is it worth it?

Advantages of generic layer: - Would allow developping applications on top of this generic layer in a uniform manner, whatever ORM runtime is used. However this would then means that the developper does not really care of what ORM runtime is used, nulling the interrest of the whole idea! Still maybe a scenario for such an approach would be to be able to use the best ORM runtime that fits best for given constraints and still let the developper code in the same way, without having to learn the way to code against a new ORM. Constraints can be number of rows, number of tables, level of relations, inheritences schemes etc. maybe a given ORM runtime perform best that other depending on structure and size of database. - Linked to previous point: there would be an easy way to compare performance of the ORM runtimes by just switching the ORM! - Linked to previous two points, but I agree maybe too much Generate code for several ORMs and Introduce intelligence at runtime to switch from one runtime or the other to imrove performance, depending on which runtime would perform best for a given scenario. OK I admit, this is cutting hair in 4

Drawbacks of generic layer: - Extra layer, therefore potentially performence loss - Generic layer, therefore not possible to easily tale advantage of specificities of each ORM runtime - Some users would just not like having to code against this generic layer, because they want to code against what they know, be it EF, Llblgen, NHibernate etc... - Difficulty of writting such a layer

Well, don't know what you think about all this... Just food for thoughts

Kind Regards Walter

the thing is that the layer on top of the entity classes, isn't really code which can be generated unless you have a lot of meta-data besides the entity model. Also, all o/r mapper frameworks supported have different characteristics and APIs, we really don't want to go there.

What we want to do in the future is offer templates which generate additional code which makes it easier to work with these frameworks.

Otis wrote:

the thing is that the layer on top of the entity classes, isn't really code which can be generated unless you have a lot of meta-data besides the entity model. Also, all o/r mapper frameworks supported have different characteristics and APIs, we really don't want to go there.

What we want to do in the future is offer templates which generate additional code which makes it easier to work with these frameworks.

Well, makes sense indeed. There is no point making code generic just for the sake of it. And beeing able to take advantage of competitive advantages of each framework is good. And in the light of providing a common toolset and designer for all ORM frameworks, it makes even more sense as people will want to use their favorite ORM they are used too, with just extra support of a fully fledged designer.

And yes, extra templates for each framework will be great!