2

I have an interface

public interface ITask { IPart Part { get; set; } } 

When I implement this interface the compiler will be happy with

public virtual IPart Part { get; set; } 

or

public IPart Part { get; set; } 

However EF needs the property to be virtual as explained here.

I keep forgetting to implement it the right way. Is there some way I can ensure that it must be?

Note I complete the interface as follows;

public virtual IPart Part { get { return TemplatePart; } set { TemplatePart = (TemplatePart)value; } } 

Is the "virtual" actually irrelevant because I am not declaring a navigation property ?

5
  • 1
    Only thing i can suggest is that if you use VS 2015 you can write your own roslyn code analyzer which will perform this checks based on some criterion(for example mark all such interfaces with specific attribute). Commented Mar 26, 2016 at 0:39
  • @alexei-levenkov I changed the question title to the 2nd part of my question, to avoid being a duplicate. Is this OK? Commented Mar 26, 2016 at 2:28
  • I think the answer might be that it only needs to be virtual if something needs to override it. This wont be the case for a property which is just returning a cast of another property. Commented Mar 26, 2016 at 5:32
  • 1
    Casting to one implementation defeats the purpose of interfaces. Also, I wonder how you're going to use this with EF, that doesn't support interfaces. Further, EF doesn't need the property to be virtual. It's you who may need it, if you want lazy loading. I don't see any reason to enforce lazy loading as standard behavior. Commented Mar 26, 2016 at 20:08
  • @GertArnold I am setting up my business classes in Dev Express XAF. They act as EF Business classes for Code First and also XAF generates the UI from them. Hence the presence of interfaces. (Apologies for not tagging that earlier) Commented Mar 27, 2016 at 2:17

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.