在我的项目中,我通常没有单独的数据访问层,但出于性能原因,我喜欢向我的实体添加一些原始 SQL 方法。
所以我的一个实体类中有一个 MassUpdateSomethingAndPersist() 。要进行大规模更新,我需要dbContext.Database.ExecuteSqlCommand
从实体内部调用。但当然我首先需要对 DbContext 的引用。
问题
是否可以从实体中获取 DbContext?对此使用反射对我来说不是问题,因为无论如何这些都是相对繁重的操作。
在我的项目中,我通常没有单独的数据访问层,但出于性能原因,我喜欢向我的实体添加一些原始 SQL 方法。
所以我的一个实体类中有一个 MassUpdateSomethingAndPersist() 。要进行大规模更新,我需要dbContext.Database.ExecuteSqlCommand
从实体内部调用。但当然我首先需要对 DbContext 的引用。
问题
是否可以从实体中获取 DbContext?对此使用反射对我来说不是问题,因为无论如何这些都是相对繁重的操作。
我认为您正在尝试做的事情表明存在 OO 设计缺陷。更新数据库不应该是实体类的责任。那是DBContext
.
所以
如果您想执行自定义 SQL,您应该在上下文中从调用者执行它,而不是从实体本身内部执行。
可以在此处找到一个示例:DBContext Native SQL Queries。
有可能的:
((IObjectContextAdapter)dbContext).ObjectContext.ObjectMaterialized += (sender, e) =>
{
(e.Entity as IEntityWithDbContext).DbContext = dbContext;
}
public interface IEntityWithDbContext
{
public DbContext DbContext { get; set; }
}
public partial class User : IEntityWithDbContext
{
public IEntityWithDbContext.DbContext DbContext { get; set; }
}
但这仍然是一个设计缺陷......
鉴于您的描述,您应该能够轻松地制作MassUpdateSomethingAndPersist()
DbContext 的方法(即MassUpdateSomethingAndPersist(something)
)。
在实体框架中,您应该遵循实体的域驱动设计 (DDD) 概念,即它始终是持久性无知的。如果您按照您的要求打破这种模式,那么您可能会发现进行适当的单元测试非常困难。
对象在数据库中修改其自己的表示的模式称为Active Record 模式,实体框架不鼓励这样做。如果您想使用 Active Record 模式,请查看为其设计的框架 - 例如Castle ActiveRecord。