Tag: dbcontext

entity framework6 DBContext只包含所有表的子集: 我们有一个包含770个表的庞大数据库，并希望使用EF 6.1x进行一些性能测试。我们只想查询这770个表中的5个。是否可以创建一个只有5-6个实体/ DBSets的“轻”DBContext，而不是使用完整的770-tables-context？当我们使用完整上下文时，一个包含4个连接的简单查询需要45秒。那是44秒太长了。我们正在使用代码优先（逆向工程）。问题：当我们创建完整上下文的这种“轻型”版本（即仅5个表）时，EF抱怨所有与这5个表有某种关联的所有其他实体都缺少密钥。我们只映射这5个表的键，属性，关系，而不是其余的。由于用LINQ编写的查询只查询5个表，因此EF应该忽略其他765个表，但它不会。为什么不？ LazyLoading = true / false似乎与此无关。注意：显然，可以在DB中创建一个视图，该视图使用LINQ查询执行我们在代码中所做的操作。问题是可以使用上面的“轻”DbContext来完成。有上下文的“轻”版本： public class ItemLookupContext : DbContext { static ItemLookupContext() { Database.SetInitializer( null ); } public ItemLookupContext() : base( “Name=ItemLookupContext” ) { //Configuration.LazyLoadingEnabled = true; } public DbSet Identities { get; set; } public DbSet Items […]

EF代码优先：inheritance的dbcontext创建两个数据库: 我正在尝试创建一个基本dbcontext，其中包含所有常用实体，这些实体将始终在多个项目中重用，如页面，用户，角色，导航等。这样做我有一个ContextBase类inheritanceDbContext并定义我想要的所有DbSet。然后我有一个Context类inheritanceContextBase，我在其中定义项目特定的DbSet。这些类定义如下： public class ContextBase : DbContext { public virtual DbSet Users { get; set; } //more sets protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Configurations.Add(new UsersConfiguration()); //add more configurations } } public class Context : ContextBase { public DbSet Buildings { get; set; } //some more project specific sets protected override void OnModelCreating(DbModelBuilder […]

使用EF DbContext实现2个接口的dependency injection: 给定一个实现2个接口的DbContext，如下所示： public interface IQueryEntities { IQueryable Users { get; } IQueryable Computers { get; } // other IQueryable get properties } public interface IUnitOfWork { int SaveChanges(); } public class MyContext : DbContext, IQueryEntities, IUnitOfWork { // implement interfaces using EF } 第一个问题，从命令方面（SaveChanges）中分离出DbContext（IDbSets）的查询方面是一个坏主意吗？我正在探索上面的重构，因为在很多情况下我们只需要查询数据，而不保存任何内容。我遇到的问题涉及统一DI，它目前使用IUnitOfWork接口的单个每个http上下文生命周期注入MyDbContext。我不确定如何为IQueryEntities接口设置注入，以便它可以重用已经针对IUnitOfWork接口注入的现有DbContext实例。或相反亦然。这有可能吗？这是当前的生命周期管理器，它在同一个http上下文中重用以前注入的IUnitOfWork实例： public class UnityHttpContextLifetimeManager : LifetimeManager { […]

避免在同一个DbContext上同时运行多个任务的entity framework错误: 我在一个运行带有Sqlite的Entity Framework Core的Dotnet Core项目中有一个WebApi控制器。动作中的此代码会出现错误： var t1 = _dbContext.Awesome.FirstOrDefaultAsync(a => […]); var t2 = _dbContext.Bazinga.FirstOrDefaultAsync(b => […]); var r1 = await t1; var r2 = await t2; 错误是： Microsoft.EntityFrameworkCore.Query.RelationalQueryCompilationContextFactory：错误：迭代查询结果时数据库中发生exception。 System.ObjectDisposedException：已关闭安全句柄 Microsoft.EntityFrameworkCore.Query.RelationalQueryCompilationContextFactory：错误：迭代查询结果时数据库中发生exception。 System.InvalidOperationException：只能在连接打开时调用ExecuteReader。对我来说这两个错误都表明DbContext会发生一些事情，比如过早处置（虽然不是DbContext本身）。 DbContext是在控制器构造函数中使用Dotnet Core的管道“通常的方式”注入的，配置如下所示（来自我的Startup.cs ConfigureServices方法体）： services.AddDbContext(options => options.UseSqlite(connectionString)); 如果我将上面的错误产生代码改为： var r1 = await _dbContext.Awesome.FirstOrDefaultAsync(a => […]); var r2 = await _dbContext.Bazinga.FirstOrDefaultAsync(b => […]); …我没有看到提到的错误，因此得出的结论是在我的DbContext的同一个实例上同时运行多个任务（如上所述注入）是导致问题的原因。 […]

在SaveChangesentity framework之后，延迟加载不起作用: 在下面的函数中，在context.SaveChanges（）之后，实体PropertyType始终为null。我刚刚使用ObjectContext转换为DBContext（首先是数据库），在更改之前，它工作正常，现在却没有。有什么我想念的吗？我检查PropertyTypeID并且它被正确写入并存在于db中。所有关系都在db和edmx文件中正确设置。生成的.tt文件将PropertyType对象显示为虚拟对象。这是EF 5。这是代码（已删除实体属性的非重要分配）： private ListingTransferDetail BeginListingTransferDetailReport(int PropertyTypeID) { ListingTransferDetail transfer_detail = new ListingTransferDetail(); transfer_detail.PropertyTypeID = PropertyTypeID; using (IDXEntities context = new IDXEntities()) { context.ListingTransferDetails.Add(transfer_detail); context.SaveChanges(); TransferProgress += “” + DateTime.Now + “: Transfer initialized for property type \”” + transfer_detail.PropertyType.DisplayName + “\”.”; } return transfer_detail; } 提前致谢。编辑我发现如果我在SaveChanges（）之后添加这行代码，它就可以了。 […]

DbContext和连接池: 在我inheritance的应用程序中，这是在基本控制器中，应用程序中的每个其他控制器都inheritance自。 public BaseController() { db = new MyDbContext(); db.Database.Log = s => Debug.Write(s); } public MyDbContext() : base(“name=MyDbContext”) { // hack to force Visual Studio to deploy the Entityframework.SqlServer package var instance = SqlProviderServices.Instance; } 由于应用程序的设计方式，每个请求至少创建2个上下文。（这是一个MVC应用程序，每个页面都调用HomeController以及为特定页面调用其他控制器。）我的问题是DbContext创建与SQL Server的连接？是在创建上下文时，还是仅在执行查询时？如果它是前者，那么我将使用两倍于SQL服务器的连接数量而不是需要的数量，如果它是后者那么它可能不是太大的问题。我不认为我能在不久的将来重构这一点，当然也不是没有道理的。我应该注意这个设计有哪些潜在的缺陷？ entity framework6.1.3

手动将DbContext提供给DbMigrator: Platform .NET 4.5和Entity Framework 6。问题我有以下代码来执行迁移： //The following function just returns an object of the Configuration() class //generated by code migrations var migratorConfig = currentMigrationProvider.CreateDbMigrationConfiguration(); var dbMigrator = new System.Data.Entity.Migrations.DbMigrator(migratorConfig); dbMigrator.Update(); 问题是Update（）函数尝试创建我的DbContext类的实例，并且由于一些好的原因，我需要手动创建上下文并将其提供给dbMigrator。那可能吗？怎么样？

是DbSet 。本地使用的东西需要特别小心吗？: 几天来，我一直在努力从存储库（ DbContext ）中检索我的实体。我试图在primefaces动作中保存所有实体。因此，不同的实体一起代表了对我有价值的东西。如果所有实体都是“有效”，那么我可以将它们全部保存到数据库中。实体“a”已存储在我的存储库中，需要检索以“validation”实体“b”。这就是问题出现的地方。我的存储库依赖于DbSet类，它与Linq2Sql（ Include()导航属性（例如））配合使用。但是， DbSet不包含处于“已添加”状态的实体。所以我（据我所知）有两个选择：使用ChangeTracker查看哪些实体可用，并根据其EntityState将它们查询到一个集合中。使用DbSet.Local属性。 ChangeTracker似乎需要一些额外的努力来让它以某种方式工作，以便我可以使用Linq2Sql来Include()导航属性，例如 DbSet.Local对我来说似乎DbSet.Local 。它可能只是名字。我只是读了一些表现不佳的东西（比DbSet 本身慢）。不确定这是否是虚假陈述。具有重要EntityFramework经验的人能否对此有所了解？什么是“明智”的道路？或者我看到了幽灵，我应该总是使用.Local属性吗？使用代码示例更新：出了什么问题的一个例子 public void AddAndRetrieveUncommittedTenant() { _tenantRepository = new TenantRepository(new TenantApplicationTestContext()); const string tenantName = “testtenant”; // Create the tenant, but not call `SaveChanges` yet until all entities are […]

我应该将我的应用程序上下文与用于标识的ApplicationDbContext分开吗？: 在Visual Studio 2013中，创建ASP.NET项目时，它会生成一个文件IdentityModels.cs ，其中包含一个ApplicationDbContext类，该类inheritance自IdentityDbContext ，最终inheritance自DbContext 。我应该仅为帐户相关实体保留此上下文，并为应用程序中的所有其他实体创建单独的上下文，还是应该将其混合使用。任何安全问题或理由不在一个上下文中包含我的整个应用程序的所有实体？

entity framework6 – 使用我的getHashCode（）: 有一定的背景可以通过这个 – 请忍受我！我们有一个使用EF的n层WPF应用程序 – 我们通过dbContext将数据从数据库加载到POCO类中。销毁dbContext，然后用户就可以编辑数据。我们使用Julie Lerman在她的书“Programming Entity Framework：DBContext”中建议的“状态绘画”，这样当我们将根实体添加到新的dbContext进行保存时，我们可以设置是否添加，修改或保持每个子实体等等。。当我们第一次这样做时（早在2012年11月！）我们遇到的问题是，如果我们添加到dbContext的根实体具有相同子实体的多个实例（即，链接到用户的“任务”记录， “状态历史记录”也链接到同一用户）进程将失败，因为即使子实体是相同的（来自同一数据库行），它们也被赋予不同的哈希码，因此EF将它们识别为不同的对象。我们修复了这个问题（早在2012年12月！），通过在我们的实体上覆盖GetHashCode，如果实体来自数据库，则返回数据库ID，如果实体尚未保存，则返回唯一的负数。现在，当我们将根实体添加到dbContext时，它足够聪明，可以实现多次添加相同的子实体并正确处理它。自2012年12月以来我们一直运作良好，直到上周我们升级到EF6 …… EF6的一个新“function”是它现在使用它自己的Equals和GetHashCode方法来执行更改跟踪任务，忽略任何自定义覆盖。请参阅： http ： //msdn.microsoft.com/en-us/magazine/dn532202.aspx （搜索“减少对编码风格的干扰”）。如果您希望EF管理变更跟踪，但是在断开连接的n层应用程序中，我们不希望这样做，这很好，实际上这会破坏我们的代码，这些代码已经运行了一年多。希望这是有道理的。现在 – 问题 – 有没有人知道我们可以告诉EF6如何在EF5中使用我们的 GetHashCode和Equals方法，或者是否有人有更好的方法来处理将根实体添加到具有重复子实体的dbContext在它，以便EF6会满意吗？谢谢你的帮助。对不起，很长的post。更新已经在EF代码中查看过，看起来像是通过获取实体的哈希码来设置InternalEntityEntry（dbEntityEntry）的哈希码，但是现在在EF6中使用RuntimeHelpers.GetHashCode（_entity）检索，这意味着我们被覆盖实体上的哈希码被忽略。所以我想让EF6使用我们的哈希码是不可能的，所以我可能需要专注于如何将实体添加到可能具有重复子实体的上下文而不会扰乱EF。有什么建议？更新2最烦人的事情是这种function的变化被报告为好事，而不是，正如我所看到的，这是一个突破性的变化！当然，如果你有断开连接的实体，并且你已经用.AsNoTracking（）加载它们以获得性能（并且因为我们知道我们将断开它们，所以为什么还要跟踪它们），那么dbContext没有理由覆盖我们的getHashcode方法！更新3感谢您的所有意见和建议 – 非常感谢！经过一些实验后，它似乎与.AsNoTracking（）有关。如果使用.AsNoTracking（）加载数据，则重复的子实体是内存中的单独对象（具有不同的哈希码），因此存在状态绘制问题并在以后保存它们。我们之前通过覆盖哈希码修复了这个问题，因此当实体被添加回保存上下文时，重复的实体被识别为同一个对象并且只添加一次，但我们不能再使用EF6执行此操作。所以现在我需要进一步研究为什么我们首先使用.AsNoTracking（）。另外一个想法是，EF6的更改跟踪器应该只对其主动跟踪的条目使用自己的哈希码生成方法 – 如果实体已经加载了.AsNoTracking（），它可能应该使用来自底层实体的哈希码吗？更新4现在我们已经确定我们不能继续在EF6中使用我们的方法（重写的哈希码和.AsNoTracking），我们应该如何管理对断开连接的实体的更新？我用blogposts / comments / authors创建了这个简单的例子： […]