dbcontext

问题 I am using Entity Framework 5 ( DBContext ) and I am trying to find the best way to deep copy an entity (i.e. copy the entity and all related objects) and then save the new entities in the database. How can I do this? I have looked into using extension methods such as CloneHelper but I am not sure if it applies to DBContext . 回答1: One cheap easy way of cloning an entity is to do something like this: var originalEntity = Context.MySet.AsNoTracking() .FirstOrDefault(e => e.Id == 1); Context

问题 When should one call DbContext.dispose() with entity framework? Is this imaginary method bad? public static string GetName(string userId) { var context = new DomainDbContext(); var userName = context.UserNameItems.FirstOrDefault(x => x.UserId == userId); context.Dispose(); return userName; } Is this better? public static string GetName(string userId) { string userName; using(var context = new DomainDbContext()) { userName = context.UserNameItems.FirstOrDefault(x => x.UserId == userId);

问题 Here\'s the table Users UserId UserName Password EmailAddress and the code.. public void ChangePassword(int userId, string password){ //code to update the password.. } 回答1: Ladislav's answer updated to use DbContext (introduced in EF 4.1): public void ChangePassword(int userId, string password) { var user = new User() { Id = userId, Password = password }; using (var db = new MyEfContextName()) { db.Users.Attach(user); db.Entry(user).Property(x => x.Password).IsModified = true; db.SaveChanges(

问题 I am getting into the Entity Framework, but I am unsure if I am missing a critical point in the code-first approach. I am using a generic repository pattern based on the code from https://genericunitofworkandrepositories.codeplex.com/ and have created my entities. But when I try to access or modify the entity I run into the following: System.InvalidOperationException: The entity type Estate is not part of the model for the current context. It happens when I am trying to access it from my

问题 My impression to date has been that a DbContext is meant to represent your database, and thus, if your application uses one database, you\'d want only one DbContext. However, some colleagues want to break functional areas out into separate DbContext classes. I believe this comes from a good place -- a desire to keep the code cleaner -- but it seems volatile. My gut\'s telling me it\'s a bad idea, but unfortunately my gut feeling is not a sufficient condition for a design decision. So I\'m

问题 I have been reading a lot of articles explaining how to set up Entity Framework\'s DbContext so that only one is created and used per HTTP web request using various DI frameworks. Why is this a good idea in the first place? What advantages do you gain by using this approach? Are there certain situations where this would be a good idea? Are there things that you can do using this technique that you can\'t do when instantiating DbContext s per repository method call? 回答1: NOTE: This answer