entity framework玩法体验(Code first)

之前加入的公司，一直都是用ADO.NET+DataTable的模式,一般是先建表，然后用codesmith生成数据层代码，间或自己有试玩下entity framework，之前的是Db first，感觉运行速度真心不达标。所以项目中一直都是ADO.NET 2.0 ，再弄个小框架，开发效率还是相当高的，而且如果你的程序需求比较杂乱(特别是企业应用系统)，你的查询就不乏各种inner join，如果自己写sql，用以下cross join，inner hash join，查询速度可以从数分钟缩减到数秒钟。另外，如果是多表查询，特别多join的，我还是建议自己写sql，自行优化你的sql，表的数据量大了后，优势还是特别明显的。
最近在学ABP框架，那就好好地再试试code first吧。

1.不习惯
以前有了需求，会先哪笔画一画流程，写一写怎么设计，确定方案后，先建数据表，再去生成实体。现在是直接在代码写实体去生成数据库。
2.数据表建立与实体建立效率
实际上如果对数据表没什么要求，code first这样的建表,建实体速度还是挺快的，但如果想让数据表名以及字段名和实体有所不同，是需要多写不少代码，其实也有点麻烦。
3.如果有外键(如果你的程序有高并发要求，你建不建外键？)
直接在数据库建表，我们习惯是建完表，然后对着关系写个外键字段，做个对应关系就行，这样好理解，也挺直观的。
而code first:

public class OrderHead
{
    [Key]
    public int OrderId { get; set; }
    public string OrderNo { get; set; }
    public string OrderType { get; set; }

    public virtual ICollection OrderDetail { get; set; }
}

 public class OrderDetail
{
    [Key] 
    [Column(Order = 1)]
    public int OrderId { get; set; }//多主键
    [Key]
    [Column(Order = 2)]
    public int OrderRowNo { get; set; }//多主键
    public string productName { get; set; }
    public int productId { get; set; }
    [ForeignKey("productId")]//product对象的外键是productId，不定义则自动生成
    public virtual Product product { get; set; }
}

需要自己在主表写个public virtual ICollection OrderDetail { get; set; }，说明表头对应了多个明细。
一开始，这么写我是有点不适应，以前是在OrderDetail表写个OrderHeadId，现在是在OrderHead写个ICollection。

优点：
未完待续。。。