dbcontext

MVC 3 + EF 4.1 I'm choosing between two approaches to deal with DbContext: Instantiate in Application_BeginRequest , put it into HttpContext.Current.Items and dispose in Application_EndRequest . Create disposable UnitOfWork (kindof wrapper for DbContext ) and start each controller action with using(var unitOfWork = new UnitOfWork()) { ... } Share your experience please: Which one would you prefer? what are pros and cons for each approach? I would suggest you use a Dependency Injection framework. You can register your DbContext as per request container.RegisterType<MyDbContext>()

Given the following code, how does EF/DbContext knows about the change made to the customer object: class Program { static void Main() { using(var shopContext = new ShopContext()) { var customer = shopContext.Customers.Find(7); customer.City = "Marion"; customer.State = "Indiana"; shopContext.SaveChanges(); } } } public class ShopContext : DbContext { public DbSet<Customer> Customers { get; set; } } public class Customer { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public string City { get; set; } public string State { get; set; } }

In EF 4.1+, is there a difference between these 2 lines of code? dbContext.SomeEntitySet.Add(entityInstance); dbContext.Entry(entityInstance).State = EntityState.Added; Or do they do the same thing? I'm wondering if one might affect child collections / navigation properties differently than the other. When you use dbContext.SomeEntitySet.Add(entityInstance); the status for this and all its related entities/collections is set to added, while dbContext.Entry(entityInstance).State = EntityState.Added; adds also all the related entities/collections to the context but leaves them as unmodified. So

I'm using the DbContext class within code that I am creating that is based on the Generic Repositories and Unit of Work design patterns. (I am following the guidance here .) While working on this project I have encountered the ObjectContext class. I've read quite a number of posts that discuss ObjectContext vs. DbContext . While some of what I've read makes sense, I still don't have a complete understanding of the differences and this leaves me wondering about my current implementation. Should I be using DbContext , ObjectContext or both? Is using one of these now considered an anti-pattern?

public partial class ProcessContext : DbContext { static ProcessContext() { Database.SetInitializer<ProcessContext>(null); } public ProcessContext() : base("Name=ProcessCS") //Comes from Config File { } --DBSets protected override void OnModelCreating(DbModelBuilder modelBuilder) { --Code } } This is a Multi Tenent DB where we have 3 Different DB's. Centralized DB is in common location and would not be changed. This is where rest of the DB details will be stored. I need to create the Connection string @ runtime where the details will be coming from this centralized DB. Can some one please let

In my solution I have 2 projects that use Entity Framework 6. Each points to a different database, both using the same data provide - SQL Server. A third project in my solution needs to use both databases. My problem is how to configure those context. I tried to create a configuration class in a separate assembly: namespace OSAD_Base { class EfDbConfiguration : DbConfiguration { public EfDbConfiguration() { SetProviderServices(SqlProviderServices.ProviderInvariantName, SqlProviderServices.Instance); } } } and referencing to this configuration in each context class: namespace IntegrationDb {

I'm a bit stumped. From what I've read setting the DbContext.AutoDetectChangesEnabled to false should disable change tracking requiring one to call DbContext.DetectChanges in order to identify changes to be sent to the database. However, it is clear from my logs below that the changes are being registered by dbContexts change tracker, even with the setting set to false. Am I missing something? Entity Framework Version: 5.0.0.0 DbContext class public class ProjectContext : DbContext { public DbSet<Project> Projects {get;set;} } Controller class private ProjectContext db = new ProjectContext();

So EntityFramework 6 is a lot better testable then previous versions. And there are some nice examples on the internet for frameworks like Moq, but the case is, I prefer using NSubstitute. I've got the "non-query" examples translated to work with the use of NSubstitute, but I can't get my head around the 'query-test'. How does Moq's items.As<IQueryable<T>>().Setup(m => m.Provider).Returns(data.Provider); translate to NSubstitute? I thought something like ((IQueryable<T>) items).Provider.Returns(data.Provider); but that didn't work. I've also tried items.AsQueryable().Provider.Returns(data

I used to implement my repository classes as you can see below public Class MyRepository { private MyDbContext _context; public MyRepository(MyDbContext context) { _context = context; } public Entity GetEntity(Guid id) { return _context.Entities.Find(id); } } However I recently read this article which says that's a bad practice to have data context as a private member in your repository: http://devproconnections.com/development/solving-net-scalability-problem Now, theoretically the article is right: since DbContext implements IDisposable the most correct implementation would be the following.