之前加入的公司，一直都是用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> 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> OrderDetail { get; set; }，说明表头对应了多个明细。
一开始，这么写我是有点不适应，以前是在OrderDetail表写个OrderHeadId，现在是在OrderHead写个ICollection<OrderDetail>。
优点：
未完待续。。。
