Originally posted by Charles McGuire:
Performance is better as my SQL statements are finely structured to retrieve exactly what I want. There isn't a huge ORM layer in between that has to inflate data objects.
Assuming that you're talking about retrieving complete rows when only a subset is needed, then that's not what ORMs generally do (maybe some do). A query that specifies a subset will retrieve a subset, not more. And no row-wrapping objects will be created, either.
Constraints and validations are defined to the DB, so I don't have to worry about something bypassing the ORM validations with a tool outside of the application. Data integrity is very high.
Using an ORM doesn't change any of this. Some applications choose to manage constraints and validations in the DB; some choose to do it in the DB. I'm not sure how using an ORM -which is free to do or not do these things- makes a difference in this regard.
application bloat via ORM and all the fragility that comes with it.
Can you explain what you mean by fragility? What kinds of scenarios do you have to guard against when using an ORM that you didn't without one?