Francesco Aliverti-Piuri on How-To-Select an O/R Mapping Tool for .NET (2006)

Be sure that your development team has clear ideas about the existing or desired database and OO architectures before selecting an object-relational mapping tool for your .NET applications. Do not expect that you will also buy an architecture suitable for your IT world when buying the object-relational mapping tool, unless you start from scratch. Your team's clear ideas should cover major decision items, like which language to use and how to map RDBMS concepts and constructs to OO concepts and constructs, especially when there is no simple correspondence.

Avoid being too .NET-oriented, unless your whole IT is based on .NET. Make sure that interoperability with, and openness toward, "other planets" have deep roots in your object-relational mapping tool candidates. Other planets include Business Process Management, standards relevant to your IT and vertical industry or business sector, and Java.

Do not focus excessively on microfeatures that allow customization of your object-relational mapping approach. Fine tuning and local optimizations are best kept for a late stage in the development cycle, when the bulk of your software performs reasonably and uniformly well. Otherwise, you might enter a maintenance nightmare if most aspects of your mapping are treated differently for each entity, relationship, or class.

If your object-relational mapping requirements are not trivial in quantitative terms (number of entities, relationships, constraints, procedures, classes, and methods), evaluate carefully the ability of the candidate tools to let you automate repetitive tasks or you might end up clicking your way repeatedly through the same tool wizards. Wizards are great for simple projects, but can lead to costly, repetitive, and error-prone work on large projects, especially if you plan to apply object-relational mapping several times during the lifecycles of your projects.

Test the object-relational mapping candidates on appropriate standard sample database schemas. If your IT department uses SQL Server, forget about pubs and Northwind, and test the object-relational mapping tool on AdventureWorks. See how much metadata the tool can extract and manipulate. The more metadata that can be extracted, the better the tool; beyond tables, views, and relationships, the tool should be capable of extracting information about constraints and stored procedures. If your IT department has standardized on Oracle, suitable sample schemas are HR, OE, and QS. For metadata extraction, refer to this article from Kathleen Dollard's "Code Generation in Microsoft .NET." Two articles on Somusar's Web site (here and here) explore the aforementioned sample schemas.

Be sure to also evaluate the consulting service associated with the tool. Simple, flexible tools with an excellent consulting service are most likely to provide your IT department with the appropriate object-relational mapping solution, unlike feature-rich, all-in-one products lacking on-site consulting.