So you might say that you have full flexibility with an O/R mapper because you can control the mapper with settings files and commands. That is partly true but it also makes everything more complex. And if you are in a big project, people will come and go and the competence of the mapper with them. Suddenly people start adressing the database directly or make mapping settings that drags down the performance of your application.
No, I do not like O/R mappers. Period.
Of course, it is usually nice in the start getting to code quickly, but it is equally bad in the end when you are struggling to find obscure performance problems or other issues in your project. And it is still much easier to find people who knows databases than say NHibernate.
O/R mappers are for lazy programmers who believes that there is one good way to map objects to databases.
This is an interesting link and the title a nice quote if you want to read more.
Still most of us still needs to get those objects into a database. The bulk of all software projects out there involves a relational database that passes through an object oriented language up to the GUI. So in a way we all need to O/R map.
I am also a lazy programmer. And I hate to put time to doing boring copies of my classes in SQL with statements or stored procedures to read and write data between the objects and the database. It is a repetetive, non-creative work best suited for zombie slaves. But I am also a control freak who dont want to lock up important business logic in a black box.
So what is my solution to this?
Code generation.
Code generation is however a beast that can be more complex than the solution you create depending on which tool you use. Programmers have a tendency to try to find the perfect solution for everything and the code generators out there have a tendency to get more and more complicated to be able to cope with every situation and complicated tools do not help you, they hinder you.
Also, when it comes to code generation regarding O/R, most tools start with the database model and builds an object graph from it. Isn't that stupid? The object model is much richer than a relational model so if you choose that direction you will lose some of that.
Besides it feels like programming anno 1986 to start with the database. SQL -86 was not especially different from SQL today.
My take on this is a small script out on beta testing right now and hopefully soon on codeplex called CreateSchema. It is a very simple and small extension method to objects that generates the SQL schema for that class. More info about that soon!
C U.
