Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a PHP developer who started with CodeIgniter. In it, designing models was easy: it seemed like each method defined in models was the equivalent of static methods in a normal, objected-oriented environment.

I tried FuelPHP, which has an built-in active record style ORM, and PHP ActiveRecord to use with CodeIgniter. I found creating models was easy with ORM, and taught me best practices when designing models.

However, I didn't like that I was tied to a specific ORM implementation, and as I got better with SQL, I thought ORMs were a bit heavy when compared to how quickly I could retrieve stuff with SQL.

But when I try to design models from scratch without ORM, I'm lost: The ORM system of one class per table and queries with eager loading makes sense, and seems like worth the performance hit for using ORM.

In what situations should I avoid using ORM? How can I design models without using ORM, so that I can use SQL directly?

share|improve this question
    
Other choice could be small query builder FluentPDO –  user1088039 Jan 17 '12 at 23:11
add comment

2 Answers

up vote 6 down vote accepted

I didn't like the fact that i was tied to a specific ORM implementation...

Why not? Are you afraid you will pick the wrong one? That sounds like a case of "Not Invented Here." You are going to be dependent on the chosen language, and SQL, and the web framework, and a dozen other things. An ORM is just one more.

As long as the performance through an ORM is adequate, I would use it. If the ORM-generated queries are too slow for some pages, then create a SQL view or stored procedure to retrieve precisely the needed information, and map the results to a custom presentation class. Use the ORM for the mapping if it is convenient, otherwise you can map the SQL result set to an array of objects yourself.

share|improve this answer
    
in cases i have faced till now, ORMs usually generate decent queries if used properly(at least the ones i have used). And the way they arrange the data is pretty handy. What i'd like to see is a situation in which ORM is bad to use. –  kapv89 Jan 6 '12 at 17:54
3  
@kapv89 If you simply don't want to use an ORM since it would tie you to a specific ORM, I'd suggest separating your Data Access Layer into it's own library and that way if you want to use a different ORM you're simply replacing the DAL. –  Rachel Jan 6 '12 at 17:59
    
@Rachel i guess thats all i want .. a DAL .. thanks .. though i am looking for best-practices on making one and then using it in the model-layer .. can you point me to something?? –  kapv89 Jan 6 '12 at 18:06
1  
@kapv89 Usually I don't recommend the DAL get used by the Models. Instead have your Controller use the DAL, and have the DAL use the Models for saving data to the database. There are plenty of examples if you do a Google search for Data Access Layer - Just pick one that uses a language you're familiar with –  Rachel Jan 6 '12 at 18:36
    
yeah.. thats what i figured, and started implementing in a project .. so I go back to classes having static function which return well structured results .. CI style .. heh –  kapv89 Jan 6 '12 at 19:52
add comment

In your OP you asked for an instance when using an ORM is "bad". I wouldn't go so far as to say ORM is bad, but it has consequences, not all of which are good.

  1. ORM's generally follow the Active Record pattern* (because Data Mapper is a bit tricky)
  2. this tends to impose design decisions on the database that favour application code

Here's a great quote from an article by Bill Karwin that sums up why this may not be such a great pattern (I couldn't find the thread on SO where it's referenced...): http://karwin.blogspot.com/2008/05/activerecord-does-not-suck.html

A single Model class may be backed by a database table, or multiple database tables, or perhaps even no database tables. Data persistence should be an internal implementation detail within a Model; the external API of the Model class should reflect its logical OO requirements, not the physical database structure.

With regards to "DAL", this is a deceptively simple acronym that encompasses a range of patterns. Personally I prefer using query generators like Zend_DB or NotORM, and writing custom methods to describe the relationships as and when I need to. It takes a bit more hand cranking, but you get intimate with the Domain Model (as opposed to the ORM Model...) and the database that supports it.

There are a couple of classic books on this subject that are well worth a read if you can track them down:

Data Access Patterns : Clifton Nock

Handbook of Relational Database Design

As an aside, it seems somewhat tragic to abandon RDBMS design and the SQL to interrogate it to the application layer! It may not be the new thing on the block, but it's a remarkable bit of technology expressing some very refined concepts that are arguably more robust than the short term design phase that will be applied to the immediate needs of a project. I've seen way too many apps that leave integrity constraints in the application layer, or fail to take into account the indexing/querying methods employed by the DB platform they are using. ORMs are undoubtedly a clever bit of kit, but so is SQL...

Here's another great quote on the subject that expresses this sentiment (with reference to the Table Module pattern:

In many ways this approach treats the relational database like a crazy aunt who's shut up in an attic and whom nobody wants to talk about http://martinfowler.com/eaaCatalog/tableModule.html

and here is another thread on SO that is very pertinent to this subject: Constraints in a relational databases - Why not remove them completely?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.