ASP.NET 在使用Entityframework的过程中，用不到Code Frist，有必要去手动创建实体类么？是否直接使用EF自动生成的实体更好些

[贾昭凯]

如题：ASP.NET 在使用Entityframework的过程中，用不到Code First，有必要去手动创建实体类么？是否直接使用EF自动生成的实体更好些。

[Justin-Liu]

EF不是可以根据数据库生成实体类吗？

[贾昭凯]

引用 1 楼 FoxDave 的回复:

EF不是可以根据数据库生成实体类吗？

对呀，本来就是有根据数据库自动生成的实体类，可是现在这个项目经理非要自己去构造EF的底层框架，然后手动去创建EF实体类，我不理解他这种做法，放着EF自动生成的不用，非要自己去手动创建那些底层的东西，还想手动去创建EF，让他给我解释这样的好处，他说不出来啥，只说个提高效率。 我就来这问问，他那手动创建EF底层框架和手动创建EF实体类，又不是要用Code First，他这样做有必要么？

[Justin-Liu]

是不是做个中间层啊，能提高一定的灵活性，但拿效率说。。。挺扯淡

[手抓宝]

不用code first，老板还不让用db first，它让你自己定义model关系原型，还有一种方式叫做model first。其实他已经说的很清楚了。

[newtee]

参考nopcommerce里面那样写吧

[software_artisan]

根据数据库自动生成的类其实用处不大。。。。但是，如果完全不用的话，那用EF干啥？自己写sql加上sqlhelper不是更直接高效？

[roc121]

code first 适合快速重构、适合开发阶段、非常适合业务的快速变化、但是如果你的业务稳定了或者说 如果你有了成熟的数据模型， 那么 code first 的确没必要

[卧槽这是我的昵称吗]

还不如就用ado.net 底层还更可控

[zujinsheng]

那么多表， 手写， 想想也是够了..

[以专业开发人员为伍]

引用 楼主 jiazhaokai1988 的回复:

如题：ASP.NET 在使用Entityframework的过程中，用不到Code First，有必要去手动创建实体类么？是否直接使用EF自动生成的实体更好些。

CodeFirst只是EF的一个工具，而手动设计实体类可能是一些很基础的开发思想的延伸。比如说你不买宝马，难道还不做公交车上班了？ 自己控制实体类，不管有没有CodeFirst工具帮助你开发，可能你的领导都要去坚持这个原则。这说明了你的领导跟你的想法是在不同层面的。你的想法是“编程只要会点数据库增删改查就行了，自己创建数据库表之后直接把数据库扔给随便什么人就行了”，而他的想法是“向各种前端需求提供灵活的设计和服务”。

[以专业开发人员为伍]

在我们的一个社交类软件中，数据库方面只有不到10个表，但是服务器端“即使是与数据库打交道的部分”也有100多个实体类（更别提前端UI的格格View等等的独立建模的类型了）。跨进程通讯命令、命令中包含的参数对象有不同的形式。如果你让一个“我只负责创建数据库表，然后别人随便怎么编写增删改查程序”的人去设计，他永远也不会给你分析设计这100个实体类，也就是说那种人永远都在花时间欣赏自己的数据库表，而不能抬头把精力放到更高层面的框架设计上来。