5 Answers, 1 is accepted
Rank 1
There's a site called ORMBattle, it's a complete farce as it was created by someone who works for DataObjects.net who are featured on the site.....just every so slightly a conflict of interest there.
It's a shame because when you search for ORM comparisons your taken there but I would disregard that site.
I've done a few projects in LINQ2SQL, the problem is the designer has some serious limitations and they effectively dropped it in favour for EntityFramework which has poor stored procedure support and no caching, if these things are important to you I'd avoid EF. LINQ2SQL was written by the C# team, not the ADO.NET team and it shows as it's not as bloated as EF.
It really depends on your requirements, if you want to use WCF, RIA services etc, is a model designer important etc ? Model 1st approach etc, stored procedures.
I've done a lot of research into this area, gone to the lengths of creating mappings on product features etc,2 other ORM's came close but OpenAccess ticked the most boxes on paper for us, you really have to look yourself at what you need and do a bit of digging about.
ORM's and data layers seem to produce some very heated debates and some people seem to have agendas and axes to grind, it makes it hard to make an informed choice, it really surprised me when I started looking at ORM's in some depth.
As you have guessed choosing an ORM to use is quite a difficult task as it is a serious investment to learn using one properly and it will make for a critical part of your application, something one cannot compromise on.
The problem is even bigger as different tools suggest different best practices and are better at some stuff than others, so it is not an easy choice. As far as Telerik OpenAccess ORM goes we take pride in certain things such as our dedicated technical support, our native database drivers, our designer and the sheer pack of functionality we provide, as well as the maturity of our runtime.
I would like to ask you to give us better perspective on what you need to accomplish so that we can get into details and how suitable OpenAccess can be for you. (Also a look into our SDK application and the examples shipped with it might be helpful).
I really hopes this proves to be helpful and would also like to thank Norman for helping out and sharing his findings.
Serge
the Telerik team
Rank 1
First I have been a long time user of both Telerik products and DataObjects.net
Recently I decided to take a look at
OpenAccess and Entity Framework. To keep this short, if you are going
to develop and maintain a completely new database these tools are a joke
compared to DataObjects. DataObjects generates
and maintain the whole database for you. You can completely forget that
it even exist AND it also updates it seemlessly. These tools on the
other hand generates scripts that must be applied to the database. They
are ignorant of what is happening if there is
an error in the scripts.
If you are attempting to create an OR layer from an existing
database I can see how they might be useful but DataObjects can also do
this. The bottom line is that DataObjects is a very mature product with a
dedicated team. These other products are relatively
new and immature in comparison and it shows. And I didn't even get to
any kind of performance metric which I am fairly sure DataObject would
easily win.
I am very surprised that Telerik is using this product for Sitefinity. I wouldn't feel comfortable using it for any serious project. In contrast we use their controls in our projects all the time.
Rank 1
DataObjects.net, last time I looked they were delighted to announce 'nightly builds' were back, hardly inspires confidence.
We went for LLBLGen in the end and we found it suited our needs and certainly ticked many more boxes than DataObjects.net (it also does all the stuff you mentioned) but I have to say I found the ORM support team very helpful and they don't deserve to have their products bad mouthed in this manner.
If DataObjects works for you then fine but it certainly doesn't mean it's the best orm out there.
DataObjects also created the utterly misleading ormbattle site.
Thank you for your feedback on Telerik OpenAccess ORM.
Regarding Alfred's overview and recommendations I would like to clarify some misconceptions.
1. OpenAccess ORM is completely free, but it has a dedicated team in Telerik which is developing new features and releasing major improvements at least 6 times per year. It is a mature product as well - only in Telerik we are working on it for 5 years already, and it has been developed by another company for several years before being acquired by Telerik. The maturity of the product in comparison with others is also clearly visible in the huge set of free learning resources that we are maintaining - full documentation of all features (almost 1000 articles), Knowledge Base section, dozens of video tutorials, full-blown Samples Kit with over 40 solutions demonstrating OpenAccess ORM integration and this forum which already has above 3000 threads and 14000 posts in total.
2. The tools and features developed specifically for performance tuning available in Telerik OpenAccess ORM are numerous. I would recommend this blog post for a quick overview of only a few of them.
3. The reason behind Sitefinity choosing OpenAccess ORM are that there are no other ORM products on the market (that we know of), that support the rich set of features OpenAccess ORM provides for enterprise data layers, including the ability to work with dynamic modules by creating and removing types even during runtime.
4. In case you experienced any difficulties while working Model First with OpenAccess ORM, we will be thankful if you can share them - we might be able to help and guide you so that you can achieve your goals.
N Mackay, thank you for the nice words about our support services. I have noticed that two years ago you have experienced some limitations with our stored procedures support. I am happy to inform you that in the meantime one of the many improvements we have implemented is the Domain Method Editor - this short video can present its capabilities. For more complex case you can still use the ADO API directly. In case you had any other needs that OpenAccess ORM failed to satisfy, let us know and they might be addressed in our future releases.
Do not hesitate to share with us any further feedback on OpenAccess ORM you have - it always counts when we make our future plans.
Ivailo
Telerik