Question

I am using poco objects I wrote with entity framework.
I would like to know about the accessibility levels of the members that used as data fields (members that mapped to field in table from the database:
For entity named P:

public class P {
    public virtual long Id{get;set;}
    public virtual string Name{get;set;}
    public virtual long CompanyId{get;set;}
    public virtual Company Company{get;set;}
}

Does the members must be public?
Does the members must be virtual?
Does the members can be private?

What are the rules for the members accessibility?

Answer 1

This strongly depends on the approach you are using.

Model / Database first:

• Members don’t have to be public but it has some consequences. POCO property getters and setters must have same accessibility as defined in EDMX (shown in linked answer). Changing accessibility will most probably break either tracking proxies, lazy loading or both as described in link provided by @dlev.
• Members don’t have to be virtual. If you want lazy loading you must mark all mapped navigation properties virtual. If you want tracking proxies you must mark all other properties virtual.

Code first (only EFv4.1):

• In this case situation is worse. Members must be public. In special case when entity is in the same assembly as context or mapping configuration members can be internal (I skip InternalsVisibleTo because it is not very nice scenario). In case when mapping configuration is nested class of entity, members can be also private or protected but this strongly breaks whole meaning of POCO because POCO entity must contain EF dependent nested class. The whole point is that mapping is done in code and it is affected by accessibility rules.
• virtual keyword has same meaning as in Model and Database first approaches.

virtual keyword is needed because EF will create new type at runtime derived from entity type. This type is referred as proxy and it overrides behaviour in property getter and setter. In case of lazy loading it adds call to Load operation which triggers loading of relation when accessed first time. In case of change tracking proxies it informs ObjectStateManager / DbChangeTracker about each change to attached entity. If tracking proxies are not used EF must use snapshot tracking which evaluates all changes to attached entity during saving which is considered as much slower operation.