http://www.kellermansoftware.com/p-47-net-data-access-layer.aspx
I don't think developers should have to write basic database plumbing code. Years ago, writing straight ADO.NET code was tedious. The Microsoft Data Application Block made it a little better. Then NHibernate came along. We used it on many projects. Around three years ago I expressed my disgust with NHibernate. Namely, the ugly xml mapping files, the inelegant output of the SQL, the performance of the SQL, and the overt complexity of the setup. I remember distinctly telling Steve Harmon that I was going to write my own ORM. He told me not to; that I should simply extend NHibernate. Steve is a smart fellow, but I decided to write my own ORM anyway. I received several laughs from people saying that I should call the product "Not NHibernate"
Well years have gone by. There is now Fluent NHibernate which does make NHibernate a little nicer. Although I would have to say that the the convention configuration in Fluent NHibernate is about as crazy looking as creating a regular expression. Using Fluent NHibernate also decreases the flexibility of NHibernate. And of course Entity Framework is now on the scene. To be honest, I would have to say that once Entity Framework came out, I thought about killing my project. I mean the basis of my project was complete automatic mapping. Entity Framework is close. The only thing it does wrong is having to create the DbSet and the DbContext. That is completely unneeded.
There are more ORMs out there than you can shake a stick at. When I started creating the competition chart for how my ORM stacks up against all others, the list was daunting. Clearly there are a lot of other people and companies out there that have spent thousands of hours and dollars to try to solve the ORM problem. If NHibernate or Entity Framework are the bomb, why would they create another ORM? Because those companies must also consider the problem to be unsolved, otherwise they would not even have tried.
http://www.kellermansoftware.com/download/DotNetTools/Knight-Data-Access-Layer-Competition.xls
In believe that I have solved the ORM problem. Knight .NET Data Access Layer is better than NHibernate, better than Entity Framework, better than anything out there that interacts with a database. Here is why:
- ORM without any mapping files, attributes, or convention configuration. Similar to Entity Framework except no DbSet or DbContext. Flexible that you can override default behaviors with attributes, code, or xml mapping files. You choose.
- Automatic mapping of straight SQL and stored procedure output to objects without any mapping files.
- LINQ to SQL Server, LINQ to Oracle, LINQ to MySQL, LINQ to VistaDB, LINQ to Sqlite, LINQ to MS Access, and LINQ to Firebird
- Wrapper for ADO.NET to perform standard operations such as executing sprocs.
- Generate databases from namespaces.
- Synchronize namespaces to a database.
- Generate classes from tables.
- Standard patterns built in that we all love. Session factory, unit of work, active record.
