Home » PHP » PHP MVC Frameworks » ORM vs Code Generation

ORM vs Code Generation

April 25th, 2010 Leave a comment Go to comments

It seems no matter where you look these days everyone is using ORMs.  Every PHP Framework you look at has an ORM and it seems the preferred way to access data and .NET also now has LinqToSql and LinqToEntities which are both just ORMs.

I look at all these ORMs and read about problems with them where they don’t generate some SQL correctly, require you to learn a new language that tries to wrap SQL but doesn’t have the same power and it really makes me sad.  People have just no idea… They are prepared to trade off control and performance for some new concept that doesn’t really add anything good.  The productivity isn’t really increased all that much and you don’t really cut down on code all that much either if you are using code generation.

Now, code generation on the other is sooo much better and I’m really surprised that it hasn’t made it into all the frameworks and environments.  Code generation takes the mundane work out of initially creating lots and lots of similar code for the likes of CRUD operations but then you can quite easily modify it as needed.  Also people have built great big libraries like NetTiers that are based on code generation, but ultimately even those aren’t really needed.  The beauty of code generation is that you can generate really lean code and hence don’t really need all the compexity.

Ultimately I think serious developers will end up going back to good old SQL and code generation after this latest ORM fad is over.  If you want to write less code then just use a code generator, not some black box that does takes up CPU cycles and spits out SQL that isn’t guaranteed to be right.

Categories: PHP MVC Frameworks Tags:
  1. April 28th, 2010 at 07:33 | #1

    Code generation stands for writing all the code for you but idea of ORM is something like “do more with less code”. It looks to me something like “car vs bike”. Yes, you can compare them but we all see the main difference – it’s not the same thing.
    In code generation I see one main point for not using it -> after (re)generation I have problems to commit created/changed files to SVN/Git repository.
    Overall I agree with you. ORM works for small websites with simple queries.

  2. April 28th, 2010 at 10:43 | #2

    Yes, I guess I should have covered that point. If you’re writing something small that’s not going to be heavily utilized by a large number of people (e.g. a very popular website) then ORM is going to work just fine, but if you’re writing a serious system it may quickly become a performance bottleneck. For example with .NET there are plenty of well documented issues with both LinqToSql and LinqToEntities. If you don’t create pre-compiled statements the performance can be very poor. Furthermore the code generated is also not always what you’d expect it to be. Furthermore ORMs I’ve worked with to date don’t seem to have query batching capabilities, which are a must if you’re processing large number of records. Same goes for actual queries generated by the ORM. If you have a large database with lots of records in your tables you need to make sure that your queries and indexes are in sync as otherwise performance can be really bad. In the past I’ve worked on large multi-million dollar projects where performance was an afterthought and I had to fight to get the right testing done, which actually showed the problems and resulted in the system having to undergo serious changes right before go-live. Just goes to show that performance should never be back of mind and (we’ll fix it if there’s a problem). Performance is something you need to think about right from the onset.

  3. May 16th, 2011 at 10:04 | #3

    I’ve had experience with all the technologies you mention in n-tier government environments.

    I think that if Linq to Sql and Linq to Entities are very poor examples of ORM’s, and probably if that is your only experience you have ORM’s your comments are probably justified.

    A proper ORM implements important Enterprise level patterns such as UnitOfWork and Repository, something that code generated CRUD stuff just wont cope with. Good ORMs also work with persistent ignorant entities, which leaves the entity free of inherited rubbish.

    With code generation, you rely on mainline style functions to coordinate all the domain entities to maintain state, connection and transaction consistency. Typically, entities in code generated scenarios contain the logic to save themselves. Hardly a separation of concerns.

    With regard to batching, NHibernate supports ADO batching against SqlServer. Also, NHiberate is open source, hardly an “black box” solution. It is also incredibly extensible unlike the Microsoft flavors.

    NHiberate also support lazy-loading, configurable to the per-relationship level.

    For anything beyond the most basic of crud application, IMHO ORM’s are all over code generation.

    The reason is that code generation requires a database-centric design, but the way data is stored in a relational database is not reflected in object-based domain models. Code generation of inheritance hierarchy and relationships requires restrictive conventions or metadata, by which time your on well on way to an ORM anyway.

    It is because ORM’s support domain-centered design that they are popular in Java, php, python, rails and the like. The programming problem has not changed just because your programming .Net. If code generation was so great, why hasn’t it taken off? It the easiest thing in the world to do. It hasn’t taken off because it straight jackets the code in a prescribed way of doing things.

    My point is this – if you have domain that is beyond slightly complex and your team understand and appreciate domain driven domain and S.O.L.I.D. code, then ORM’s have appeal. If on the other hand you enjoy database driven design and just want to write less code for data access then code generation might be for you. Personally, the hours I have seen developers chew up getting their templates ‘just right’ make me wonder if it’s worth it, and even then you end with both a database and a code base built based on the sensibilities of the code generation template. Not an ideal start.

    I haven’t really explained them well, but check out PoEEA or Martin Fowlers web site for more details on the enterprise patterns I’ve mentioned.

  4. May 17th, 2011 at 01:18 | #4

    Thanks XHalent, excellent post and explaination of the benefits and drawbacks of ORM vs CodeGenerators. You’re quite spot on and indeed NHibernate is much more robust solution than that provided by Microsoft. I would also recommend the Patterns of Enterprise Application Architecture by Martin Fowler that you have mentioned. Any respectable developer should have that book and the GoF Patterns book on their bookshelf.

  1. No trackbacks yet.

seven − 6 =