覆盖EF默认的约定可以通过两种方式:
1、拦截模型构建器,使用流畅的API
2、通过给 类添加标签
好的,我还用之前定义的订单类来做例子:
public class Order
{
public int OrderId { set; get; } public string OrderCode { set; get; } public string CustormName { set; get; }
}
模型构建器
使用构建器,就必须要重写 方法:OnModelCreating
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder); }
通过参数 modelbuilder进行修改其默认的约定:
modelBuilder.Entity<Order>().ToTable("efdemo.Order");//效果同下
modelBuilder.Entity<Order>().ToTable("Order", "efdemo");
上面执行的修改了表个架构,默认是根据登录的用户进行创建的数据库表的架构,sa 是dbo
下面是对表的属性就行修改:
modelBuilder.Entity<Order>().Property(o => o.OrderId).HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity);//可以设置成 自动增长的(默认是自动增长的,可以取消) modelBuilder.Entity<Order>().Property(o => o.OrderCode).IsRequired()//不能为空
.HasMaxLength()//设置最大长度
.HasColumnName("OrderBM");//设置生成数据库中表 对应的 字段名
modelBuilder.Entity<Order>().Property(o => o.CustormName).IsRequired()
.HasMaxLength();
使用标签
public class Order
{
[Required]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int OrderId { set; get; }//默认的约定;EF 查找类里面时候还有 ID后 类名+ID字段,有就将其设置为主键
[MaxLength()]
public string OrderCode { set; get; } public string CustormName { set; get; }
}
最后进行总结一下,到底是应该使用哪一个,下面就行总结:
首先先论述各自的优点:
使用模型构建器:
优点:流畅的API,支持泛型委托:Lambda表达式,很爽。并且可以使用链式编程
有智能提示,有编译时的错误检查
纯粹的POCO,没有修改模型
使用 标签:
优点:简单明了,并且可以实现错误检查
但是他们也有的各自的不足,比如:
1、使用标签不能对表名,表的架构进行修改
2、使用构建器,不能对字段的 最小长度进行设置
3、使用构建器,不能对字段的正则表达式进行设置
但是将构建器和标签结合起来就可以实现了,
所以我认为:
使用构建器约束数据类型,
使用标签来丰富我们的模型。