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.
4 comments:
What I'm seeing in the market seems to be trending into one of 3 camps. First, you have the people standardizing on Entity Framework. These are the ones who think anything Microsoft does is great for whatever reason - availability of support, books, online help, and/or experienced talent for hire. Then you have the people who're moving away from the leaky and bloated ORM abstractions back to SQL, but doing it in a much smarter way by using micro ORMs like Dapper and Massive. These are the folks who, like me, understand the SQL is a great DSL for data access, and repository wrappers around your DAL mean you have good separation of concerns rather than trying to cram your relational model into your business domain objects. And finally you have those who are fed up with the relational model all together and are moving towards NoSQL databases like MongoDB or CouchDB. While still niche, these are coming on strong because the products are so compelling. Development is fast. There's no object/relational impedance mismatch. Concerns like "enterprise readiness", reporting, and ETL look to be on the near horizon. Time will tell, but any developer who's gone this route will tell you it's tough to go back because of how powerful and simple these database are.
Sadly, what I don't see are people looking for new ORM solutions - especially ones you have to purchase. All the direction is towards free, simple, stable, and widely accepted. You have an uphill climb my friend, but I wish you the best and hope you prove me wrong. Who knows, maybe you'll distribute some freebies to some loud mouths who'll love it and evangelize for you. I'll bet you could get Ayende to do a code review for you and blog about it for a few days (http://ayende.com/blog).
I wish the assignment that I was on was one of those three camps. We are using Spring Framework .NET which is essentially a wrapper around ADO.NET that is worse than ADO.NET.
Matt, I am not expecting any sales. The goal of the project was to win at ORM for me; and I have done that. It will also benefit my Gold Suite customers. They wouldn't purchase the product separately but it gives them value for their subscription.
What were your design goals? What didn't the existing ORMs offer that made you undertake this. Was it just a dislike for nHibernate? Have you read this series? http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-series/
The design goals were: simplicity, flexibility, and granular control. The main deficiency with the existing frameworks was the lack of auto mapping, lack of auto SQL mapping, and lack of a pass through to ADO.NET. Some had only partial LINQ support. Support for POCO was also essential. Davy Brion's blog is similar to the bulk of the ORMs out there; falling short with auto mapping. At the end of the day, Knight Data Access Layer can save an object with only two lines of code; no mapping. No other ORM can accomplish that.
Post a Comment