entity-framework-4.3

问题 While we mostly use fluent configuration for our code-first POCOs, we have found it useful to use data annotations for things like the table name, PKs, etc. since it makes it easier for non-EF components that don\'t have a reference to the ObjectContext to interact with these entities. In our experience, it seems that the two configuration styles can be mixed freely, with fluent configuration overriding DataAnnotations. Is this documented anywhere? Is there any risk to doing this mixed

问题 I am using Entity Framework 4.3 and using Code Fist. I have a class public class User { public int UserId{get;set;} public string UserName{get;set;} } How do I tell Entity Framework that UserName has to be unique when creating database table? I would prefer to use data anotations instead of configuration file if possible. 回答1: In Entity Framework 6.1+ you can use this attribute on your model: [Index(IsUnique=true)] You can find it in this namespace: using System.ComponentModel.DataAnnotations

问题 I have a question regarding the .AsNoTracking() extension, as this is all quite new and quite confusing. I\'m using a per-request context for a website. A lot of my entities don\'t change so don\'t need to be tracked, but I have the following scenario where I\'m unsure of what\'s going to the database, or even whether it makes a difference in this case. This example is what I\'m currently doing: context.Set<User>().AsNoTracking() // Step 1) Get user context.Set<User>() // Step 2) Update user

问题 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