API / Apache Grails Interview questions
Why do we use GORM instead of writing raw SQL/JDBC?
Raw JDBC requires a developer to manually write SQL, manage connections and statements, map result sets back into objects by hand, and coordinate transaction boundaries explicitly — a substantial amount of repetitive, error-prone plumbing for what's conceptually a simple "save this object" or "find records matching this condition" operation.
GORM removes essentially all of that plumbing for the common case: declaring a domain class is enough to get a real database table, and calling .save(), .findBy...(), or building a DetachedCriteria query handles schema mapping, SQL generation, and object hydration automatically. It also brings in features raw JDBC doesn't give you for free — optimistic locking through the version property, cascading saves/deletes across relationships, and validation constraints enforced consistently wherever the domain class is used.
None of this makes raw SQL obsolete inside a Grails application — GORM still allows dropping down to native queries or HQL for cases where its abstractions don't fit — but for the large majority of everyday persistence operations, GORM eliminates boilerplate that would otherwise be rewritten, slightly differently, in every application that touches a database directly through JDBC.
More Related questions...