1. The Programming Language is factor in how well ORMs integrate into your app. If you're using a language which is expressive enough or has native support for

1. The Programming Language is factor in how well ORMs integrate into your app. If you're using a language which is expressive enough or has native support for querying, ORMs are an excellent fit. An example of a language in which ORMs work well is C#, on account of LINQ. But if you're on Java, it isn't as appealing. Hibernate still has value and is a very mature solution, but is nothing close to the expressiveness you get in LINQ. 2. Performance is good enough, but with caveats. Some ORMs (especially newer ones) don't handle entity relationships very well, and sometimes do 1+N queries to fetch a single object. For eg, if you have a customer with an orders property, a naive ORM might SELECT the customer first, and issue separate SELECTs for loading each of the Orders. Entity Framework had this problem earlier, which they resolved later. 3. Always watch the actual queries with a database tool. 4. Be careful about Lazy Loading. Lazy loading defers the actual load until you use it. If the code always uses a property (that needs to be loaded from the DB), always eager load. eg: if you have 100 customers, and you usually need customer.creditCard, eager load "creditCard" (resulting in a join) to avoid 1+100 queries. 5. You probably don't need an ORM with NoSQL. 6. Inheritance relationships can be tricky, and have performance consequences. You can choose to have a (1) Table for the entire class hierarchy, or (2) a table for each Class. With (1), you get an ugly wide table with lots of fields and faster performance. With (2), if you were to select a list of Animals, and have Cat, Dog, Rabbit tables, you'll get cleaner tables - but poor performance because of joins. Add: generally avoid mapping inheritance via ORMs. 7. Built-in caching, which you can find in some ORMs is probably not worth it. 8. ORMs need not replace 100% of your queries. Some functionality will work better with SQL or even Stored Procedures - let it be. 9. ORMs let you compose queries. I'll not go into details, but you could compose getCustomersByCountry() and getCustomersByAgeGroup() to get getCustomersByCountry_and_Age(). 10. Depending on the size of your project, see if patterns like Repository make sense (even if you're using ORMs). 11. Last, the most important detail. It is not actually about saving lines of code - as much as it is about the ability to refactor. The biggest win from ORMs (in a statically typed language) is that if you edit a property, it changes the property across all files including your queries. Without an ORM, the code degrades quicker - because developers are reluctant to change.