Cloud Nine Squad {C-iX}

ORMs are my newfound love. They truly make the birth of my 3rd child look second-rate.

Zorro, do you use these types of tools? Got an opinion on them? I love cutting my data access layer development time down to virtually nothing. Beautiful, just beautiful.

I think Zorro died.

ORMs are overhead, inefficient, and result in lots of unnecessary layers in an application. For a small database with a half dozen tables, you likely won't notice the layers and inefficiency. For me at least, when I'm working with a database with tens of millions of records and 50 or so tables, I've found ORMs to be more trouble then they're worth. Google "object-relational impedance mismatch" for more information. Long story short, I abhor ORM solutions. This is, of course, a highly controversial opinion.

He hath spoken.

I figured that was the reply I would get.

I read Wikipedia's page on object-relational impedance mismatch. I understand the problems with the ORM approach, but to me, they don't seem to outweigh the benefit of cutting development time down significantly. It seems to me that all of those issues have possible workarounds. Assuming ORM is actually limiting some functionality, it's not as if you can't integrate both approaches.

I suppose I'll learn much more when I join a professional development team, but I'll be using them for my own applications as much as I can. I suppose your opinion will also be influenced by the ORM technology you have available. The .NET languages have recently introduced the Entity Framework Model, and it's a pretty extensive approach. Something developed by Microsoft that is .NET-language specific has probably given me an unfair, biased introduction.

Well ORM is a hot topic for debate, and my opinion is far from unbiased as I'm mostly limited to my ORM experience in a PHP environment (Doctrine, Propel, and RedBean). The biggest problem I find when using an ORM solution on really large projects is handling records with really complex one-to-many, many-to-one, and many-to-many relationships. All an ORM really does is write [inefficient] SQL queries on behalf of the developer. When retrieving data, it compiles the results into usable objects or arrays. When inserting data, it compiles the objects/arrays into SQL queries. In other words, it's just layers and layers of automation. It sounds cool at first, but I've found it only leads to frustration down the road, since the developer never really knows for sure what's going on further down the stack.

When I built version 1 of my PHP framework (VinePHP), the biggest problem I had to force myself to overcome was to not overly automate things; because the more automated a code library becomes, the less portable it becomes. Like version 1, the second version of VinePHP (currently in the planning phase) is going to expound on the philosophy of less-is-more.

Just popping in again to say I have saved so much time in my most recent project with the Entity Framework for C#.