【发布时间】:2012-03-20 05:10:53
【问题描述】:
我有大量实现业务逻辑的类。大多数都有一个 .Load 方法,它使用普通的旧 ADO.net 从我多年来手工编写的 Sql Server 读取值。这一切都早于 Linq2Sql 和 EF。
现在我想更新我的类库以使用实体框架,但我想尽可能轻松地做到这一点。我了解到 EF 可以从我的类中的属性名称推断列名称和键名称,但是我的类有许多与列名称不对应的属性和一些与数据库的列名称不匹配的属性。我宁愿不必 .Ignore() 每个属性(并记住始终 .Ignore() 任何未来的属性)和 .HasColumnName() 所有差异。
将 EF 与现有表和现有类一起使用的最简单方法是什么,这样我就可以进行最少的映射,并且仍然使用 DbContext 来 .Find() 实体和 SaveChanges() 以及 EF 支持的所有其他不错的强类型事物手动浏览我的所有业务类并注释要包含的属性?
例如,我希望能够 db.Customers.Find(123) 并让它创建一个 Customer 实例,从 CustomerID=123 的客户中选择 *,并将确实存在的列映射到尽可能最好地存在的属性,并为我提供一个准备好使用的客户实例,然后我可以根据需要注释任何差异。这是可能的还是我对 EF 的要求太高了?
是否有更智能的 DbContext 可以尽最大努力映射属性,以便我可以利用所有现有的业务类?也许我应该考虑其他一些 ORM?
【问题讨论】:
-
其他 ORM 帮不了你。如果您同时拥有数据库和类,则必须始终努力为每个类创建正确的映射。