关于EntityFramework的问题
0
悬赏园豆：40
[已解决问题]
解决于 2013-06-03 15:39
使用的版本是EntityFramework5.0.0，.Net版本是4.0，不过遇到的问题应该都比较初级，于版本影响差异不大。
1.使用code first，还要写一堆attribute，感觉如果公司项目用，db first现实一点，pdm->db->实体。
但是有个问题就是这样就必须使用外键让实体关联起来，那好吧，只能加上外键，然后去掉强制外键约束，用起来还是不加外键那样（不知有什么深层区别）。
我有个疑问就是，能不能db first和code first结合起来用，比如我通过pdm生成了数据库，然后生成对应的实体（没有外键，也就没有关系），接着，我手动地在各个实体中加入了这样的关系（类似于code first那样），比如让A实体中有一个B实体的属性，通过配置EntityKeyProperty确定主键，通过一种“默认契约”的形式完成配置。
2.在我设置了外键关系的时候，db first生成的实体中多出一个“导航属性”，但是基元属性里面依然有一个冗余字段
比如A.ID是主键，B.AID是外键，在生成的B的实体中，有一个A类型的对象，但是还有一个AID。。。这不是多余吗，在哪里配置能去掉？
好久前刚出code first模式的时候，就大概用过EF。现在感觉就是，玩玩还行，真要用他，好别扭啊！！我还是再看看FluentData去。。
最佳答案
1
路过，帮顶，忘完了。
收获园豆：40
脱离他那个生成机制的话，要做的修改有点多，得不偿失。
现在比较看好fluentData和dapper，估计在这俩里面选一个，或者ibatis.net。
没人回答啊，结贴了！
其他回答(2)
1
T4模版里面的*.tt文件用XML方式打开,在这里面进行修改,就能修改所有的模版;
T4模版弊端就是你对属性修改只要执行,就会重新给你改回去(.tt模版执行缘故)
说实话用EF里面T4模版的真心不多,有兴趣可以玩玩,不熟悉的话修改起来很麻烦熟悉的话,改好后用起来还是不错的,拖拽一个.tt文件满世界跑.
0
两个ORM的思路就不一样，fluentData还是封装，还是给你SQL之外的选择，比EF轻量是真的。
Dapper是扩展，什么叫扩展？就是不破坏原有架构设计，增加之外的东西，性能上Dapper稍微快一点，不分伯仲。
相比之下，Dapper更容易扩展，更加和谐，不会让人猛一看就头大。如果是我，要么纯ADO.NET，要么Dapper，要么Entity Framework。
另外，如果要生成实体，自己写TT是最好的选择。
@Sirius丶西毒: 最后生成实体用的是codesmith，orm在Dapper和FluentData中选择了FluentData，做了一点点扩展。
