问题描述
如题：ASP.NET在使用Entityframework的过程中，用不到CodeFirst，有必要去手动创建实体类么？是否直接使用EF自动生成的实体更好些。
解决方案
本帖最后由 jiazhaokai1988 于 2015-05-21 15:45:58 编辑
解决方案二：
EF不是可以根据数据库生成实体类吗？
解决方案三：
引用1楼FoxDave的回复:
EF不是可以根据数据库生成实体类吗？
对呀，本来就是有根据数据库自动生成的实体类，可是现在这个项目经理非要自己去构造EF的底层框架，然后手动去创建EF实体类，我不理解他这种做法，放着EF自动生成的不用，非要自己去手动创建那些底层的东西，还想手动去创建EF，让他给我解释这样的好处，他说不出来啥，只说个提高效率。我就来这问问，他那手动创建EF底层框架和手动创建EF实体类，又不是要用CodeFirst，他这样做有必要么？
解决方案四：
是不是做个中间层啊，能提高一定的灵活性，但拿效率说。。。挺扯淡
解决方案五：
不用codefirst，老板还不让用dbfirst，它让你自己定义model关系原型，还有一种方式叫做modelfirst。其实他已经说的很清楚了。
解决方案六：
参考nopcommerce里面那样写吧
解决方案七：
根据数据库自动生成的类其实用处不大。。。。但是，如果完全不用的话，那用EF干啥？自己写sql加上sqlhelper不是更直接高效？
解决方案八：
codefirst适合快速重构、适合开发阶段、非常适合业务的快速变化、但是如果你的业务稳定了或者说如果你有了成熟的数据模型，那么codefirst的确没必要
解决方案九：
还不如就用ado.net底层还更可控
解决方案十：
那么多表，手写，想想也是够了..
解决方案十一：
引用楼主jiazhaokai1988的回复:
如题：ASP.NET在使用Entityframework的过程中，用不到CodeFirst，有必要去手动创建实体类么？是否直接使用EF自动生成的实体更好些。
CodeFirst只是EF的一个工具，而手动设计实体类可能是一些很基础的开发思想的延伸。比如说你不买宝马，难道还不做公交车上班了？自己控制实体类，不管有没有CodeFirst工具帮助你开发，可能你的领导都要去坚持这个原则。这说明了你的领导跟你的想法是在不同层面的。你的想法是“编程只要会点数据库增删改查就行了，自己创建数据库表之后直接把数据库扔给随便什么人就行了”，而他的想法是“向各种前端需求提供灵活的设计和服务”。
解决方案十二：
在我们的一个社交类软件中，数据库方面只有不到10个表，但是服务器端“即使是与数据库打交道的部分”也有100多个实体类（更别提前端UI的格格View等等的独立建模的类型了）。跨进程通讯命令、命令中包含的参数对象有不同的形式。如果你让一个“我只负责创建数据库表，然后别人随便怎么编写增删改查程序”的人去设计，他永远也不会给你分析设计这100个实体类，也就是说那种人永远都在花时间欣赏自己的数据库表，而不能抬头把精力放到更高层面的框架设计上来。