EF的DbContext是否应包含所有表? [英] Should EF's DbContext contains all tables?

查看:54
本文介绍了EF的DbContext是否应包含所有表?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是EF4的新手,我试图找出创建DbContext类的最佳方法.

I'm new to EF4, and I'm trying to figure out the best way to create my DbContext class(es).

将我的所有表/实体放入一个且只有一个DbContext类是否有问题(特别是性能),就像下面的代码一样?

Is there any problem (specially performance) in putting all my tables / entities into one and only one DbContext class, like the code below?

public class AllInOneDb : DbContext
{
    public DbSet<Customer> Customers{ get; set; }
    public DbSet<Address> Addresses{ get; set; }
    public DbSet<Order> Order{ get; set; }
    public DbSet<Product> Products{ get; set; }
    public DbSet<Category> Categories{ get; set; }
    // and more and more entities...
}

还是应该基于功能子集为我的课程建模?

Or should I model my classes based on the subsets of functionalities?

public class CustomerDb : DbContext
{
    public DbSet<Customer> Customers{ get; set; }
    public DbSet<Address> Addresses{ get; set; }
    public DbSet<Order> Order{ get; set; }
}

public class ProductDb : DbContext
{
    public DbSet<Product> Products{ get; set; }
    public DbSet<Category> Categories{ get; set; }
    public DbSet<Order> Order{ get; set; } // look Order entity again!
}

谢谢

推荐答案

如果您的子区域具有特定的业务逻辑,则可以将其拆分为多个 DbContext .(这些较小的上下文遵循对域驱动设计至关重要的模式称为有界上下文).创建针对这些各种过程而不是一个通用的DbContext有很多好处语境.随着应用程序的增长,维护每个上下文以及在其中定位所需的逻辑将变得更加容易.(比在具有许多 DbSet 属性和许多类的流利配置的单个 DbContext 中添加或修改现有逻辑更好)

If you have sub areas which have specific business logic, you can split it into multiple DbContext. (These smaller contexts follow a pattern critical to Domain Driven Design called Bounded Contexts). There are a number of benefits to creating DbContexts that are targeted to these various processes rather than one all-purpose context. As your application grow, it will be much easier to maintain each context as well as locate the logic you need within it. (Better than adding or modifying existing logic in single DbContext with many DbSet properties and fluent configuration for many class)

性能是另一个考虑因素.当实体框架创建内存时上下文模型,上下文越大,则将更多的资源用于生成并维护该内存模型.

Performance is another consideration. When Entity Framework creates an in-memory model of the context, the larger the context is the more resources are expended to generate and maintain that in-memory model.

如果要在多个上下文之间共享实例( Order ),则实体一次只能附加到一个上下文.首先从客户DbContext分离订单,然后将订单附加到产品DbContext.而且,您应该注意(或避免避免)将已添加",已修改"或已删除"实体从一个上下文移动到另一个上下文.

If you are going to share instances(Order) between multiple contexts, Entity can only be attached to one context at a time. Detach Order from the Customer DbContext first and attach Order to a Product DbContext. And you should be careful about (or just avoid) moving Added, Modified, or Deleted entities from one context to another.

Order order;
using (var custDb = new CustomerDb()){
   order = custDb.FirstOrDefault(o=>OrderId == "orderid");
}
using (var prodDB = new ProductDb()){
   prodDB.Attach(order);
   ...
}

这篇关于EF的DbContext是否应包含所有表?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆