大家来说说Entity Framework有哪些问题？

很多人都说Entity Framework不好，哪究竟具体有哪些问题呢？

需要转化，比原生态SQL语句要慢些，相比来说。

我使用EF的CodeFirst的时候，我新建了实体类，然后建一个实体类对应的Context类，每次新建实体类都需要新建Context类，我想把Context操作实体
的类抽象成一个泛型类，可是发现不行，有什么好的解决方案吗？
RoleDBContext ctx = new RoleDBContext();

    public void Add(Role role)
    {
        ctx.Roles.Add(role);
        ctx.SaveChanges();
    }

    public IEnumerable<Role> GetAll()
    {
        return ctx.Roles.AsEnumerable<Role>();
    }
            UserDBContext ctx = new UserDBContext();

    public void Add(User user)
    {
        ctx.Users.Add(user);
        ctx.SaveChanges();
    }

    public IEnumerable<User> GetAll()
    {
        return ctx.Users.AsEnumerable<User>();
    }

            想抽象成
    //public class ContextBase<T> : DbContext
//{
//    public ContextBase()
//        : base("MyDBConn")
//    {
//    }
//    public DbSet<T> Users { set; get; }
//}

（1）需要额外的学习，这是最致命的问题。低端开发者最不愿意的就是学习，特别是在他们现有的技术还可以完成任务的时候。
任何技术都有利弊，但是抱着这样的心态，自然掩耳盗铃地过滤掉有利的那一面，无限放大有弊的那一面，于是心安理得地觉得什么也没有必要再学了。
（2）性能问题，性能问题没有传说中的那么严重，但是的确存在，起码在理论上。因为又包了一层嘛，接口调用开销是存在的。特别是，如果你不会LINQ，甚至也不会SQL。
仅仅抱着完成任务的态度写查询，那写出很低效的查询也在所难免了。好比你用不恰当的算法，即便用汇编你也可能写出很低效的程序一样。另一个问题是，LINQ翻译的SQL不如手工写SQL那么直观。
特别需要指出的是，SQL也可能写出低效的查询。
（3）不能最大化利用数据库全部的特性。LINQ毕竟是一个抽象层，它只使用SQL语法、函数中的一部分，同时对于数据库的一些高级特性，比如内存表、群集等等缺乏直接的支持，当然，这些东西也可以间接地去使用。
（4）一些第三方的Provider不是很完善，有bug。比如EF to Oracle的某个版本存在将字符串变量直接当作字面值翻译到SQL中这样的问题，比较诡异。当然有时候也有程序员自己搞错了不求甚解怪罪EF的情况。
（5）当编写程序节约的人工成本相比提高程序运行效率节约的运维成本微不足道的时候。我经常打一个比方，复印机和胶印机的关系。很多人说复印机印图书又慢又贵。但是复印机的好处是在印刷批量很小的时候它因为不用制版所以又方便又便宜。当然在大规模的印刷中它就不如胶印机了。一样的道理，这个世界上99%的程序都是满足某一类很少的人的各种各样不断变化的需求的。EF和很多技术虽然没有使得我们能做的事情更多（其实C#能做的事情不比用汇编语言多）但是降低我们做相同的事情耗费的时间精力。但是往往剩下的1%的程序因为更加知名往往被津津乐道。

我是想用一个泛型类去继承一个Base的泛型类，在base里面写Add,GetAll这些方法。然后具体的类去override，或者直接调用base的，但是泛型类无法继承
base非泛型类，即DBContext