我将在一个大项目中使用Entity Framework 4。
我知道许多专业程序员建议依赖我的业务类而不是EF模型类。
实际上我的大脑内部有声音告诉我“不要依赖于那些生成的课程！只要用你的东西弄脏你的手就不要让别人为你做这件事。!!”
但实际上我不知道在这么大的“企业”项目中使用这些生成的类的问题在哪里。
所以请让我理解为什么???
答案 0 :(得分：5)
使用EF生成的类绝对没有错。这就是他们的目的。
但是，如果你误用了这项技术，你就会遇到很多问题。例如，许多初学者将尝试将这些EF生成的类用于所有。他们将接受这些类，使用WCF或Remoting将它们整理到AppDomain边界，也许他们会在前端绑定它们。这可能适用于快速而肮脏的基于CRUD的应用程序，但它不会用于任何具有任何实际大小的任何东西。
为什么不呢？因为EF生成的类是在应用程序的数据“域”中建模的，而不是表示“域”。用户可能想要与之交互的内容通常不是数据库中具有表的1：1对象。例如，用户可能具有“产品”网格。在该网格内部将是产品的总销售额，以及关于产品的某些指示性数据。虽然指示性数据（名称，大小等）可能会直接从Product表中生成，因此从EF生成的Product类，但汇总数据（已售出的总金额）是一个总值。
我们通常在服务中使用EF生成的类，然后使用该服务将EF类转换为ViewModel，然后使用WPF（或您喜欢的任何技术）在我们的前端绑定。这让我们分离了我们正在寻找的问题。
答案 1 :(得分：1)
除了Dave的好答案之外，我还想提到使用生成的类的另一个重要缺点：它们来自一个公共基类（EntityObject）。如果您的现有域模型具有自己的继承层次结构，则可能会出现问题，因为.NET中不支持多重继承。
答案 2 :(得分：1)
如果您的项目很大，我建议您遵循域驱动开发。每个域类都包含许多组件：EF实体属性，行为属性注入（格式化数据，解析，转换，复制，验证，配置）。
如果您遵循单一责任原则，每个班级应该只有1个责任。 EF模型类应该用于存储数据并与EF基础结构通信以生成运行时SQL。其他课程将负责格式化，转换，验证和转移。
当类型数量增加时，您需要使用Facade模式集中或组织它们。这些Facade是特定于域的类型。因此，如果您从生成EF模型开始，然后构建支持类型（格式化程序，验证程序，...），最后创建域类型，您将无法获得更好的协作和分发能力，因为您可以通过反向获得。首先构建您的域类型，构建模拟和单元测试，然后与对等方共享它们，让它们将域对象的功能与EF模型连接起来。这就是你可以做域驱动开发的方法。
答案 3 :(得分：1)
在将EF生成的类一直暴露给Javascript时，需要格外小心。
首先，您可能会暴露出太多的领域而不是您需要的领域。这将增加有效负载并使攻击者可以轻松猜出您的数据库架构。
其次，如果您还让MVC Model Binder将HTTP（通过Request Body，URL或任何方式）数据反序列化为EF模型，然后将其直接保存到数据库中，那么您将面临极大的风险。任何人都应该能够缓和HTTP请求，向您发送一个JSON对象，该对象将覆盖您不希望的字段。想想这个购物车对象：
{cartItems: [{itemId:1, quantity:100, product:{ productId:23, price:0 }}]}
如果我可以传递价格为0且有效productId的product，则EF将覆盖数据库中指定产品的价格。