我正在整合一些遗留系统。他们每个人都有不同的数据库；我需要为其中的大多数编写数据访问代码。
无法更改数据库模式（我可能可以应用一些索引等，但表及其列必须保留结构）。一些数据库设计良好，具有适当的关系和主/外键，而其他一些数据库则非常缺乏。
您会为此任务选择哪个 ORM？我想在整个项目中使用相同的 ORM；我的要求是：
我目前对 LINQ-To-SQL 的经验最丰富；但我觉得这可能是这个项目的错误选择。我愿意花一些时间来学习一个新的框架。
猜测一下，我认为 ORM 可能会给您带来比它节省的更多的麻烦。如果您有几个不同的遗留数据库，其中一些设计不佳，您可能会发现在较低级别构建数据访问层比 ORM 更容易。Fowler 的企业应用程序架构模式在对构建数据访问层的各种方法进行分类方面做得非常好。
某些数据访问层可能适用于代码生成解决方案；但是，各种模式的存在（如您所说的有些混乱）表明，一刀切的方法可能不起作用，或者可能需要付出不成比例的努力才能使其与所有遗留数据库很好地配合使用。
nHibernate 将是您最好的选择，它提供 POCO 支持，包括对我所知道的每个数据库的支持，并且 LINQ 支持绰绰有余。听起来您会想要生成映射文件，那里有用于 mygeneration 和 codesmith 的模板，可以帮助您做到这一点并避免大量的手动工作。（在初始生成之后，很容易调整和更改表名称、关系等，这在大多数基于生成的框架中要困难得多）
LINQ to SQL 仅适用于 SQL Server。ADO.NET 实体框架适用于 ADO.NET 支持的任何数据库。
我在您的列表中看到的唯一未实现的是这些类不是 POCO。特别是，在 Web 服务中公开其中一个是一个坏主意，因为特定于实现的数据也将被序列化。
nHibernate 符合您的大部分要求。唯一的限制是 linq；但是，他们有一个由赞助商捐赠的全职开发人员，致力于添加对 linq 查询的支持。
它支持很多数据库引擎，它是免费的，可以使用 POCO 的。它有很多钩子可以使各种部件可扩展。
在我看来，最重要的因素是您是否计划实现域模型或将表直接映射到数据传输对象 (DTO)。如果您要对域进行建模，那么我绝对推荐 NHibernate。如果您打算使用 DTO，那么有很多不错的候选者，包括实体框架和数据表。
我猜你正在使用C#？
我想说也许可以试试 SubSonic，当数据库已经存在时，它是一个不错的选择，尤其是在处理存储过程和视图时。没有像 nHib 那样需要配置的 xml，您可以在几个小时内启动并运行它（或者如果您知道自己在做什么，则需要 20 分钟）。它也支持一些数据库。
我相信 Rob 和 Co. 现在正在添加 Linq 部分，因此它也可能在其中，但那将是我尚未尝试过的最新内容的一部分。