我正在开发一个应用程序，它目前通过ADO.NET和硬编码的SQL语句查询（相当大的）数据库。无可否认，这很丑陋（即，如果在SQL中犯了错误，将不会引发编译时错误）并且可能存在危险（由于SQL注入等原因，尽管这对于此特定应用程序来说不太可能是问题），但是最初并未考虑因为这个应用程序真的只对这个数据库中的一小部分表格感兴趣（至少现在是这样）。什么时候应该考虑使用ORM框架？
LinqToSQL看起来很有趣，但由于该应用程序也需要有能力连接到Oracle数据库，所以该计划是一个非启动器。
像我这样的项目，是否适合与ORM框架集成，或者会过于矫枉过正？
我认为一个ORM应该总是至少为认为是。
但它听起来并不像你甚至使用业务对象（有时称为数据访问层或DAL），这大大破坏了面向对象语言的有用性。我会首先解决这个问题。如果您发现为业务对象创建所有CRUD太耗费时间，那么可以使用ORM ...
我个人最喜欢的是nHibernate。大的学习曲线，但绝对值得。
我会推荐一个生成的DAL而不是ORM或Linq。
看看亚音速http://subsonicproject.com/。它是一款开源DAL生成器，非常易于学习和使用，开销非常低。
我自己并没有使用SubSonic，但是经常阅读作者的博客。我认为这可能是第一次进入DAL和ORM领域的一个很好的DAL。 – mkmurray 2009-07-14 04:49:52
我肯定会说它是一个ORM框架的候选人。一旦熟悉了框架，设置ORM的开销很小，好处很多。
正如您所说，如果您可能需要Oracle支持，LinqToSQL并不合适，但其他大多数框架都支持Oracle。
如果您只使用表格的一小部分，那么您将只需映射一小部分表格，因此安装成本将进一步降低。
祝你好运！
尝试使用生成sql的东西（如Linq，仅适用于Oracle），而不是orm。
报价：
“起初，你像” whee！对象！“然后你意识到 - 嘿，这是很多乏味的，容易出错的映射代码，我之前不必写......”
这看起来像http：//的副本stackoverflow.com/questions/349718/ado-net-entity-framework-decision-making-between-orm-solutions等等。搜索“Orm框架”，你会看到。 – 2009-07-14 04:41:56