An architecture review board is deciding whether a new service should use an ORM such as Entity Framework or hand-written SQL for its data access layer. Which statement best summarizes the trade-off the board should weigh?
Select an answer to reveal the explanation.
Short Explanation
An ORM is like an automatic transmission: you get moving faster and with less effort, but you give up some fine control. When a query needs that control, you have to step in yourself. The trap is believing the ORM makes queries faster by default; it makes developers faster.
Full Explanation
The core ORM trade-off is development speed versus control over SQL. Mapping classes to tables removes repetitive data-access code, keeps the model in one place and lets developers work in the application language, which shortens delivery. In return, the framework decides how statements are shaped, and mapping or fetch settings can produce inefficient patterns that the team must detect by reviewing generated SQL and occasionally override with hand-written queries. Claiming better performance on every query reverses the trade-off; generated SQL is at best comparable to well-written hand SQL and is sometimes worse. Promising complete injection protection overstates the benefit, since parameterization helps but raw query strings built inside an ORM can still be vulnerable, and ORMs fully support transactions rather than losing them. Portability to any NoSQL engine is not the point of an object-relational mapper, which targets relational databases, and start-up time is not the deciding factor. Exam caveat: hand-written SQL is not automatically faster either; it gives control, which still requires skill to use well. Operational check: for the service's critical paths, log the generated SQL in test and confirm each statement uses appropriate indexes before committing to the approach.