Entity Framework的 Fluent API 配置有点繁琐

[datahandler2]

之前的数据层都是自己写的。。。突然想用EF 6， 发现 Code first 模式下的Fluent API 配置关系的时候有点繁琐难记呀。。。
一会儿Has。。。。,一会儿With....
大家都是习惯使用在Model上面进行数据注解还是使用 Fluent API方式进行配置。。。
开发习惯我正常都是习惯设计好数据库后，再编写c# model。。。我都感觉我的开发方式针对code first模式还真不适合，

[bidisty]

你也可以先数据库再model

[以专业开发人员为伍]

Code First 模式是非常好的，原本应该是直观方便的。然而 EF 异常繁琐，所以我们根本不用 EF。 比如说只要有一个对象类型为

public class XXX
{
    private string _a;

    public string A{get;set;}

    public int B{get; set;}

    public DateTime C;

    public string D{
    get{ return C.ToString();}
    set{ C = DateTime.Parse(value); }
    }
}

只要将这样的对象执行

DbContext.Insert(obj);

，第一次涉及某个类型的对象时，那么就应该自动（根据是否需要而）产生 XXX 表，自动产生准确的 _a、B、C 三个字段，而不会多余地产生 A 和 D 字段。 而 EF 的异常烦琐之处，就在于它没有非常恰当的“默认”情况，什么都要程序员来配置。一个好的配置，前提是不配置也能自动启用那些千锤百炼而产生的默认配置。如果依赖于配置，那就说明它默认的配置都是垃圾。

[以专业开发人员为伍]

EF 一出，我们就不自己研发 ORM 了。这是我们的损失，但是是不得已的。因为我们当初没有成本预算、不可能像 EF 那么好地支持 Linq provider 机制，就没有前途。 现在，退而求其次（反正我们基本上是使用 mongodb 而不是关系数据库），我是 EF 和 ADO.NET 允许并行。而以 ADO.NET 为基本，一个程序员其所负责开发的代码可以根本不用 EF。

[以专业开发人员为伍]

public class XXX
{
    private string _a;
 
    public string A{get{ return _a;};set{_a=value;};}
 
    public int B{get; set;}
 
    public DateTime C;
 
    public string D{
    get{ return C.ToString();}
    set{ C = DateTime.Parse(value); }
    }
}

数据库表结构应该针对的是最底层的“字段”而创建，而不应该针对“属性”映射。针对属性而建数据表，是一个很不好的方式。使用了很不好的方式来识别数据库表的字段，那么就需要你用一堆配置。 其它方面也是如此。EF 的底层理念不太恰当，因此无法以“默认配置”来正确操作。它让人进行一大堆配置才能比较合理地操作。这些配置看上去高大上，其实是匹配垃圾理念的。