Menu
In the pluralsight video of http://www.asp.net/mvc. The model object member were changed to virtual in the middle of a video. He didn't give detail description of the change. Could any one elaborate the necessity?
public class Restaurant
{
public virtual int ID { get; set; }
public virtual string Name { get; set; }
public virtual Address Address { get; set; }
public virtual ICollection<Review> Reviews { get; set; }
}
BTW, is the IDBContext in the video follows repository pattern? Should the code use repository pattern for best practice if it's not?
public interface IDbContext
{
IQueryable<Restaurant> Restaurants { get; }
IQueryable<Review> Reviews { get; }
int SaveChanges();
T Attach<T>(T entity) where T : class;
T Add<T>(T entity) where T : class;
T Delete<T>(T entity) where T : class;
}
Update: It should be a variety of repository pattern. Usually repository pattern create one class for one model object IRepository<T>. This one put all the model object in one interface Restaurants, Reviews. How this one compares with the typical one?
788
In Entity Framework, using a virtual navigation property allows you to denote it as the equivalent of a nullable Foreign Key in SQL. You do not HAVE to eagerly join every keyed table when performing a query, but when you need the information -- it becomes demand-driven.
These classes (POCO classes) implements only the domain business logic of the Application. Some developers use Data Transfer Objects (DTOs) with the classes to pass the data between the layers because POCOs are also used to pass the data between the layers, but they become heavy.
A POCO entity is a class that doesn't depend on any framework-specific base class. It is like any other normal . NET CLR class, which is why it is called "Plain Old CLR Objects". POCO entities are supported in both EF 6 and EF Core.
Plain Old CLR Object is a play on the term plain old Java object from the Java EE programming world, which was coined by Martin Fowler in 2000. POCO is often expanded to plain old C# object, though POCOs can be created with any language targeting the CLR. An alternative acronym sometimes used is plain old .
To summarize this, to get POCO works with EF, it creates proxy classes that inherit from your original entity classes (POCOs). And so it needs the properties to be virtual in order to override them so that it can plug EF change tracking and lazy loading infrastructure work. Otherwise no change tracking or lazy loading would be enabled by default.
For complete answer to this you might need to read Working with POCO Entities and Requirements for Creating POCO Proxies
111
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
