为什么不在大型项目中使用EF生成的类呢?

使用EF生成的类绝对没有错。他们就是为了这个。

但是如果你误用了这项技术,你会遇到很多问题。例如,很多初学者会尝试使用EF生成的类来 . 它们将获取类,用WCF或Remoting跨AppDomain边界封送它们,也许它们将在前端绑定到它们。这可能适用于快速而肮脏的基于CRUD的应用程序,但它不会适用于任何实际大小的应用程序。

为什么不呢?因为EF生成的类是在应用程序的数据“域”中建模的,而不是在表示“域”中。用户可能希望与之交互的对象通常不是与数据库中的表1:1的对象。例如,用户可能有一个“产品”网格。在这个网格中是产品的总销售额,以及一些关于产品的指示性数据。虽然指示性数据(名称、大小等)可能会直接从产品表中删除,因此从EF生成产品类别,但聚合数据(售出的总美元)是一个聚合值。

我们通常会在服务中使用EF生成的类,然后使用该服务将EF类转换为ViewModels,然后使用WPF(或任何您喜欢的技术)在前端绑定到ViewModels。这就给了我们寻找的关注点的分离。

除了Dave的好答案之外,我还想提到使用生成类的另一个重要缺点:它们是从公共基类派生的( EntityObject ). 如果现有的域模型具有自己的继承层次结构,则可能会出现问题,因为.NET不支持多重继承。

在向Javascript公开EF生成的类时需要格外小心。

首先,你可能暴露了太多的领域比你需要的。这将增加有效负载,使攻击者很容易猜测您的数据库模式。

其次,如果您还让MVC Model Binder将HTTP(通过请求体、URL或任何方式)数据反序列化到EF模型中,然后将其直接保存到数据库中,您将面临很大的风险。任何人都应该能够调整HTTP请求,向您发送一个JSON对象,该对象将覆盖您不期望的字段。想想这个购物车对象:

{cartItems: [{itemId:1, quantity:100, product:{ productId:23, price:0 }}]}

如果我能通过 product 如果价格为0且产品ID有效,EF将覆盖数据库中指定产品的价格。

如果您的项目很大,我建议您遵循域驱动开发。每个域类由许多组件组成:EF实体属性、行为的属性注入(格式化数据、解析、转换、复制、验证、配置)。

如果你遵循单一责任原则,每个班级应该只有一个责任。EF模型类应该用于存储数据并与EF基础设施通信以生成运行时SQL。其他类将负责格式化、转换、验证和传输。