.net 实体框架是否适合替换多个数据库和动态SQL？

我已经接管了一个遗留应用程序的维护工作，该应用程序管理的项目每个项目都有一个单独的数据库（就本问题而言是相同的），目前有超过1000个数据库。此外，这些数据库没有定义表关系，而是使用查询级别的联接来确定关系。当前使用动态SQL和ADO.net提取数据

我曾希望使用实体框架提供一个公共数据访问层，根据需要使用实体框架在数据库之间切换

然而，我现在认为，由于缺少表关系（甚至不清楚哪些是1对多、1对1等），EF可能比它的价值更麻烦，我将难以定义关联和导航属性，这将使提取数据的任务更加复杂

---

我的问题是，这听起来公平吗？或者实体框架在上述场景中可以吗？

“这些数据库没有定义表关系……EF可能比它的价值更麻烦”——使用数据库优先的场景（而不是代码优先），如果您希望关联和导航属性，则在生成.NET EF代码模型之前，EF确实要求数据库已经设置了数据库级关系。是的，我同意你关于EF不合适的看法。谢谢米奇，你认为代码优先的方法行得通吗？当然可以。然而，听起来手工重新创建所有类可能需要做很多工作，但至少这样您可以定义导航属性，从而使实际的应用程序代码更容易。请注意，它不会试图重新编写您的DB架构。感谢您的警告，我认为，按照您的建议，我将把它保留为ADO.net并保存EF以供此应用程序的最终替换。我建议查看Dapper。这是一种非常灵活的微型ORM。我成功地使用了它。