A book titled "Pro LINQ Object Relational Mapping with C# 2008" by "Vijay P. Mehta" has a chapter (chapter 12) that outlines a comparison between LTS (LinqToSQL), EF (EntityFramework) and selected .NET ORM frameworks.

The author choose only 3 ORM frameworks to compare to MS's LTS/EF: NHibernate EntitySpaces LLBLGen

The author did a reasonable good job in objectifying the comparison against a pre-defined list of points:

Object-to-database mapping: This is the single most important aspect of an ORM tool. An ORM tool must have the ability to map business objects to back-end database tables by using some sort of metadata mapping.

Object caching: As the name indicates, this functionality enables object/data caching to improve performance in the persistence layer.

GUI mapping: A good ORM should have a UI that enables you to visualize the mapping and creation of metadata. Multiple database platform support: An ORM should offer portability from one RDBMS provider to another; this is one of the key advantages of using ORM.

Dynamic querying: Another important aspect of ORM, and the bane of DBAs everywhere, is dynamic query support. This means that the ORM tool offers projections and classless querying, or dynamic SQL based on user input.

Lazy loading: The purpose of lazy loading is to optimize memory utilization of database servers by prioritizing components that need to be loaded into memory when a program is started.

Nonintrusive persistence: Nonintrusive persistence means that there is no need to extend or inherit from any function, class, interface, or anything else provider-specific.

Code generation: The purists will insist that there is no place for code generation in ORM, because a well-thought-out object model should be coded by hand. In my opinion, a successful ORM will optionally support some form of code generation.

Multiple object-oriented framework support: This is when a product offers compatibility with multiple object-oriented languages and development environments.

Stored procedure support: An ORM tool should support dynamic querying and stored procedures.

The "Nonintrusive persistence" really baffled me as I did not understand it nor its value in the comparison specially that the author reported that both EntitySpaces and LLBLGen do not support it.

I also found EntitySpaces really interesting as it seems to compare so closely to LLBLGen. ES has a very interesting query API that looked very similar to LINQ's method syntax.

In the comparison, LLBLGen got high praises for its GUI and code-generation.

omar wrote:

A book titled "Pro LINQ Object Relational Mapping with C# 2008" by "Vijay P. Mehta" has a chapter (chapter 12) that outlines a comparison between LTS (LinqToSQL), EF (EntityFramework) and selected .NET ORM frameworks.

The author choose only 3 ORM frameworks to compare to MS's LTS/EF: NHibernate EntitySpaces LLBLGen

The author did a reasonable good job in objectifying the comparison against a pre-defined list of points:

Object-to-database mapping: This is the single most important aspect of an ORM tool. An ORM tool must have the ability to map business objects to back-end database tables by using some sort of metadata mapping.

Object caching: As the name indicates, this functionality enables object/data caching to improve performance in the persistence layer.

GUI mapping: A good ORM should have a UI that enables you to visualize the mapping and creation of metadata. Multiple database platform support: An ORM should offer portability from one RDBMS provider to another; this is one of the key advantages of using ORM.

Dynamic querying: Another important aspect of ORM, and the bane of DBAs everywhere, is dynamic query support. This means that the ORM tool offers projections and classless querying, or dynamic SQL based on user input.

Lazy loading: The purpose of lazy loading is to optimize memory utilization of database servers by prioritizing components that need to be loaded into memory when a program is started.

Nonintrusive persistence: Nonintrusive persistence means that there is no need to extend or inherit from any function, class, interface, or anything else provider-specific.

Code generation: The purists will insist that there is no place for code generation in ORM, because a well-thought-out object model should be coded by hand. In my opinion, a successful ORM will optionally support some form of code generation.

Multiple object-oriented framework support: This is when a product offers compatibility with multiple object-oriented languages and development environments.

Stored procedure support: An ORM tool should support dynamic querying and stored procedures.

The "Nonintrusive persistence" really baffled me as I did not understand it nor its value in the comparison specially that the author reported that both EntitySpaces and LLBLGen do not support it.

Nonintrusive in this context means: you can use POCO classes and they are persistable. LLBLGen Pro derives the entities from a predefined base class, so it's not that you can define the classes persisted.

However, POCO is really not poco. Due to the nature of the CLR, at runtime tricks have to be used to make POCO classes persistable, e.g. through proxy classes (subclasses) which have problems and a list of requirements on their own.

I also found EntitySpaces really interesting as it seems to compare so closely to LLBLGen. ES has a very interesting query API that looked very similar to LINQ's method syntax.

Still, ES lacks in features compared to llblgen pro and it seems that the ES team is a bit obsessed to become better than us or something . However it doesn't support linq natively, nor is it going to in the near future, which I think will not do them good, because the crowd who is now using linq to sql or EF and wants to move away from them, isn't going to be willing to give up linq.

In the comparison, LLBLGen got high praises for its GUI and code-generation.

Cool Not for the framework though? Well, at least we're mentioned Thanks for the heads up, Omar