ORM is not ideal for every project. If we have to grind through simple calculations on millions of records, with no user experience to worry about, we gain litt

ORM is not ideal for every project. If we have to grind through simple calculations on millions of records, with no user experience to worry about, we gain little from expressing the data as objects for a few microseconds; the cost of transformation from raw bytes to business objects is never repaid. We're better off with the fastest, native data manipulation techniques available. An object-oriented approach is better suited to highly interactive, line-of-business applications. Data records are not nearly so numerous in such applications. They live in client space for minutes or hours, not microseconds. During their unpredictable stay, they appear in various guises on multiple screens. Users change them. They're roiled in complex business logic. The consensus of architects is that such data records are best represented as business objects. The open question is how best to shuttle data between database and business object form. ORM is one such answer. Not the answer.