为什么 MS 决定使用约定而不是配置。
我处理非常大的项目，并非所有项目都以数据为中心。事实上，即使是以数据为中心的项目，我的实体类也有很多需要与持久性无关的自定义功能。
使用当前的 MSM 方法，我最终不得不将属性应用于非持久性属性，而不是相反。这不应该是代码优先的重点吗？使用工作类层次结构并将其作为“附加”转变为持久性兼容？
我了解某些约定非常有用，例如身份或主键属性和外键的命名。但老实说，如果他们还没有类结构，告诉我有多少开发人员会使用代码优先而不是模型优先？？？
问问题
1316 次
3 回答
3
您不需要在类中使用任何依赖于持久性的属性。EF 代码首先使用模型配置来定义映射 - 该配置要么直接在OnModelCreating派生 DbContext 的方法中定义，要么在每个实体和复杂类型的单独配置类中定义。属性只是转换为这些配置的快捷方式。
于 2012-04-30T15:09:32.027 回答
2
如果您正在创建适当的抽象，那么这应该不是 IMO 的问题。听起来您将业务实体和逻辑与数据实体混合在一起。如果您遵循存储库模式并抽象持久性实体，那么您的大多数 POCO 应该遵循约定。我建议重新评估您的架构，因为它听起来与持久层非常耦合。如果您创建一个更松散耦合的架构，那么这些约定对您来说应该是有意义的。只是我的两分钱，虽然
于 2012-04-30T14:48:44.667 回答
1
我已经做了很多工作，首先将代码应用于预先存在的业务对象，以创建一个不了解持久性的架构。在这种情况下应用 EF 的方法不止一种——我同意用属性修饰业务对象并不理想。我们过去所做的是
- 定义一个存储在由 DAL 实现的 BLL 程序集中的接口。这被上层用于 CRUD 操作
- 在 DAL 中，使用EntityTypeConfiguration(of T)映射业务对象
它对我们来说效果很好，并且很好地将上层与 DAL 分离
于 2012-04-30T15:25:52.920 回答