Ignore read-only class properties when using DataContext.ExecuteQuery<T>

Question

How do I tell a LINQ data context to ignore either specific properties, or all readonly properties, when binding a result set to an object?

I am working with some T-SQL statements that are difficult to express using LINQ, so I'm using the ExecuteQuery method of the data context to pass the straight T-SQL to the database.

If my class T has any readonly properties, I get exceptions at runtime when the data context tries to set those properties and fails because there's no setter property. How do I tell the context to ignore those properties?

This is what I'm doing now. It works, but it sucks:

public bool IsPaidInFull {
    get { return NetTotal <= 0m; }
    set { /* needed so linq doesn't choke. Should never be set by hand */ }
}

Burnett

May I be the first to suggest - "don't do that"? – Cherice

Don't do what, exactly? The workaround is a sin, and is unacceptable, hence my post here. If you mean "don't find a way to skip certain properties when binding to the result set", could you please explain? – Burnett

Answer 1

Have you considered Linq to Entities? It may not be worth the trouble to convert your project, depending on how far along you are, or how much orm overhead you are comfortable with. However, this exact scenario would not be a problem in Linq to Entities. It does not try to update read only properties in the object when loading it, because they are not explicitly mapped, they are simply extension properties.

Also, you could go the old-school/java route by using getter functions instead of properties. public bool getIsPaidInFull(){return NetTotal <= 0m;}.

Or you could play around with implementing the read only properties in an inherited child class, but that may introduce all sorts of type issues.

Asinine

That's not a possible solution for this project, unfortunately, but thanks for the tip. I think we might consider a full ORM in the future; L2S is great as a simple wrapper over the data model, but it can be painful to use it as a mapping layer to entities. I'm accepting your "old school" suggestion as the answer. I can't seem to find a better solution, and getter methods are better than my current workaround. – Burnett

Answer 2

public bool IsPaidInFull
{
    get { return NetTotal <= 0m; }
    private set { ;}
}

Waverley

It must have something to do with reflection used by the datacontext. I imagine the datacontext uses reflection to check to see if there is a getter and setter on your property, but doesn't check the access modifier. And then since it never actually uses the setter, there isn't any problem with access. – Waverley