EDIT: This happen only on larger scale projects with repositories. Is there anybody using EF4 with CodeFirst approach and using repositories? Please advise me.
Hi. Im currently working with EF4 CodeFirst Classes. In my test project I got two classes, Author and Book (author got books). What I'm trying to do is that I have a AddBook in my Author class, but that wont seem to work like I can't Add it to the collection.. here are my classes and two different exceptions.
public class Book
{
public virtual int BookId { get; set; }
public virtual string Title { get; set; }
public virtual Author Author { get; set; }
}
public class Author
{
public virtual int AuthorId { get; set; }
public virtual string Name { get; set; }
public virtual ICollection<Book> Books { get; set; }
public Author()
{
Books = new Collection<Book>();
}
public void AddBook(Book book)
{
book.Author = this;
Books.Add(book);
}
}
exception: The property 'Books' on type 'Author_4CF5D4EE954712D3502C5DCDDAA549C8E5BF02A0B2133E8826A1AC5A40A15D2A' cannot be set because the collection is already set to an EntityCollection.
I change the Author class to this
public class Author
{
public virtual int AuthorId { get; set; }
public virtual string Name { get; set; }
public virtual ICollection<Book> Books { get; set; }
public void AddBook(Book book)
{
book.Author = this;
Books.Add(book);
}
}
Exception: Object reference not set to an instance of an object.
cannot be set because the collection is already set to an EntityCollection.
And thats only natural that I get that exception because the Collection is not set to a new, but then I get that first exception. so how is this done with code first in EF?
maybe I should add that my It might collide with my DbSet?
public class EntityContext : DbContext, IUnitOfWork
{
public DbSet<Author> Authors { get; set; }
public DbSet<Book> Books { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.IncludeMetadataInDatabase = false;
}
public void Save()
{
SaveChanges();
}
}
Removing the "virtual" keyword from the collection properties works around the problem, by preventing the Entity Framework from creating a change tracking proxy. However, this is not a solution for many people, because change tracking proxies can be really convenient and can help prevent issues when you forget to detect changes at the right places in your code.
A better approach would be to modify your POCO classes, so that they instantiate the collection properties in their get accessor, rather than in the constructor. Here's the original Author POCO class, modified to allow change tracking proxy creation:
public class Author
{
public virtual int AuthorId { get; set; }
public virtual string Name { get; set; }
private ICollection<Book> _books;
public virtual ICollection<Book> Books
{
get { return _books ?? (_books = new Collection<Book>()); }
set { _books = value; }
}
public void AddBook(Book book)
{
book.Author = this;
Books.Add(book);
}
}
In the above code the collection property is no longer automatic, but rather has a backing field. It's better if you leave the setter protected, preventing any code (other than the proxy) from subsequently modifying these properties. You will notice that the constructor was no longer necessary and was removed.
The issue mentioned above by Dejan.S regarding the use of 'List' to initialize a collection still occurs in EF5 RTM and ASP.NET 4.5 RTM:
BUT, if you remove the virtual keyword from the primary key (e.g. UserId in the above screencap), it works! So it seems all of your properties can be virtual, EXCEPT the primary key.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With