CODEWITHSUNDEEP
c#entity-framework
zam6ak
zam6ak

Reputation: 7259

Entity Framework: read only property vs parameter-less method

Consider following class

public class AccountGroup : Entity<int>
{
    public AccountGroup()
    {
        Accounts = new HashSet<Account>();
        Groups = new HashSet<AccountGroup>();
    }

    // option 1 - read only properties
    public bool IsRoot { get { return Parent == null; } }
    public bool IsLeaf { get { return !Groups.Any(); } }
    public Account MainAccount { get { return Accounts.FirstOrDefault(a=>a.Type == AccountType.MainAccount); } }

    // option 2 - parameter-less methods
    //public bool IsRoot() { return Parent == null; }
    //public bool IsLeaf() { return !Groups.Any();  }
    //public Account GetMainAccount() { return Accounts.FirstOrDefault(a => a.Type == AccountType.MainAccount); }

    public string Name { get; set; }
    public string Description { get; set; }

    public virtual ISet<Account> Accounts { get; private set; }
    public virtual ISet<AccountGroup> Groups { get; private set; }
    public virtual AccountGroup Parent { get; set; }
}

If I want to "enrich" the class above, which option approach should I use.

Option 1

Should I use read only parameters knowing that EF does not like them (trying to use IsRoot in Where clause throws ex, with The specified type member 'IsRoot' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported.

Option 2

Or should I go with parameter-less methods (not sure what would be disadvantages)

In general (not considering EF), which approach is preferred considering above when functionality is equivalent (i.e. I get the same functionality if I invoke .IsRoot or .IsRoot())

Upvotes: 2

Views: 792

Answers (3)

48klocs
48klocs

Reputation: 6103

Have you already tried decorating IsRoot with [NotMapped]? The NotMapped attribute should prevent Entity Framework from complaining about properties that it's unable to persist and allow you to express that as a property.

Upvotes: 0

David
David

Reputation: 218857

In general (as you say, not taking limitations of EF into account), the approach for domain models in this particular context would probably be a read-only property.

Consider that the property is simply checking state, not modifying it in any way. A read-only property conveys, outside of the object, that it's just returning a piece of information. On the other hand, a method could be potentially destructive in that it might modify information.

This would be particularly true if the method returned void of course, which isn't the case here, so this could be considered a borderline issue (and not even a question in languages which don't have "properties" but just use accessor methods, which under the hood is what a "property" does).

My vote is for a property when checking state and a method when commanding the object to modify state.

Upvotes: 0

Matt Greer
Matt Greer

Reputation: 62037

IsRoot feels more like a property to me. It represents current state of the object, doesn't actually do anything when invoked other than report that state, and generally getters/setters in .NET are properties.

There are other things to consider, a JSON/XML serializer will not serialize IsRoot() but will for IsRoot as a property. Generally speaking a lot of things in .NET hinge off of properties, so often they are the better choice.

EF wouldn't like IsRoot() either, it just doesn't know how to translate IsRoot into SQL, whether it's a property or method.

Upvotes: 2

Related Questions